Discussion:
Aleph and chunked encoding
Alex Engelberg
2018-06-01 06:21:56 UTC
Permalink
Hello internet friends,

I have a server built with Yada (which is basically an Aleph HTTP server
plus some extra magic to make it RESTful) and I'm trying to make my file
upload API support requests with chunked encoding, i.e. the header
"Transfer-Encoding: chunked" is present.

As far as I can tell, Netty accepts and takes care of chunked encoding,
because my handler is getting an already-decoded stream of data with no
extra effort on my part.

However, I'm noticing a potential problem with the failure mode of chunked
encoding streams: If the client dies during the upload and terminates the
connection early, the input data stream on the server side just gets closed
with no surfaced error. This results in my API happily creating files in
the backend with incomplete data. I ideally would like to detect that the
stream ends prematurely and abort the upload rather than commit it.

Since Content-Length isn't even allowed in combination with
Transfer-Encoding (per the HTTP spec), I can't compare the amount of bytes
received with the claimed amount to ensure completeness.

In theory, since the chunked encoding protocol encodes the amount of bytes
in a chunk before the chunk itself, whatever is doing the decoding should
be able to detect premature EOF and throw an exception. However since I am
getting decoded data, I have no control over these decisions.

Is there a best practice or solution I'm missing here, or is Netty or Aleph
behaving inadequately?

Thanks,
--Alex
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aleph-lib+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alexey Kachayev
2018-06-01 07:21:57 UTC
Permalink
Hello Alex,

I assume your question relates to the discussion here:
https://github.com/ztellman/aleph/issues/381 (broader context for the
topic). With chunked encoding, it's a simpler task as you only need to
detect whether the last chunk sent by the client was empty, Netty would
wrap it into io.netty.handler.codec.http.EmptyLastHttpContent. The only one
way to catch it (at least what I can think of): attach own hander into Netty
pipeline (using pipeline-transform to replace request-handler by the name).

BR,

On Fri, Jun 1, 2018 at 9:21 AM, Alex Engelberg <
Post by Alex Engelberg
Hello internet friends,
I have a server built with Yada (which is basically an Aleph HTTP server
plus some extra magic to make it RESTful) and I'm trying to make my file
upload API support requests with chunked encoding, i.e. the header
"Transfer-Encoding: chunked" is present.
As far as I can tell, Netty accepts and takes care of chunked encoding,
because my handler is getting an already-decoded stream of data with no
extra effort on my part.
However, I'm noticing a potential problem with the failure mode of chunked
encoding streams: If the client dies during the upload and terminates the
connection early, the input data stream on the server side just gets closed
with no surfaced error. This results in my API happily creating files in
the backend with incomplete data. I ideally would like to detect that the
stream ends prematurely and abort the upload rather than commit it.
Since Content-Length isn't even allowed in combination with
Transfer-Encoding (per the HTTP spec), I can't compare the amount of bytes
received with the claimed amount to ensure completeness.
In theory, since the chunked encoding protocol encodes the amount of bytes
in a chunk before the chunk itself, whatever is doing the decoding should
be able to detect premature EOF and throw an exception. However since I am
getting decoded data, I have no control over these decisions.
Is there a best practice or solution I'm missing here, or is Netty or
Aleph behaving inadequately?
Thanks,
--Alex
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Oleksii Kachaiev,
CTO | Attendify
M: +1-650-451-2271
--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aleph-lib+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...