On 2013-10-24 17:02, Santiago Gala wrote:
On Thu, Oct 24, 2013 at 12:24 AM, Alexander Klimetschek
<[email protected]>wrote:
On 23.10.2013, at 08:00, Santiago Gala <[email protected]> wrote:
With this caveat, multi byterange support does not look like it is
working.
My second test:
$ curl -v -u admin:admin -H "Range: bytes=0-20,21-63"
http://localhost:8080/index.html
....
As curl points, the response has no chunk transfer encoding, no
Content-Length, no "Connection: close". This is violation of HTTP, one of
the three things is required or the client gets confused, as you see here
(I had to use Ctrl-C to make the test end).
Ok, you might want to report the issue with multi-byte requests on
https://issues.apache.org/jira/browse/SLING, thanks! AFAIK, the code was
taken from Apache Tomcat, and was considered stable, but you never know.
The issue is not with sling, but with curl. A multipart/* entity is
properly delimited, the --delimiter-- token marks end of it, as RFC2616
clearly says: "Unlike in RFC 2046, the epilogue of any multipart message
MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if
the original multipart contains an epilogue). These restrictions exist in
order to preserve the self-delimiting nature of a multipart message- body,
wherein the "end" of the message-body is indicated by the ending multipart
boundary."
I'm looking for the place to report it to curl so that it correctly
interprets the end boundary as ending a multipart HTTP response...
...
Such as <http://sourceforge.net/p/curl/bugs/1293/>.
This is something I consider a bug in RFC 2616, and HTTPbis is going to
fix this (see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/90>),
so this is something that needs to be fixed in Sling.
Best regards, Julian
