Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/90
Origin: http://www.w3.org/mid/gmc0k3dm7les4il70mk2682vgapah8cqn1@hive.bjoern.hoehrmann.de
Component: p1-messaging
There appears to be some confusion as to when multipart/byteranges bodies have to be inspected to determine the message length. It seems that is widely considered optional and sometimes limited to ...
In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (appendix 19.2) when it appears in a 206 (Partial Content) response ...
... this particular case, even though the specification suggest the opposite, I read it to say, all implementations have to support that and support it in all messages, like requests and non-206 responses. Apache 2.2.6 for example treats
POST / HTTP/1.1 Host: example Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES --THIS_STRING_SEPARATES ...
as two requests, a zero-length POST and a --THIS_STRING_SEPARATES to the root which it does not support (which seems to be a bug in itself).
Would it be possible, for example, to discourage implementations to ever generate messages where the message length is determined by this type, and limit having to read it to 206 responses, as the text above suggests?
Proposal as per http://www.w3.org/mid/1195473232.29661.5.camel@henriknordstrom.net
The correct resolution is to fix 4.4 Message Length to restrict rule 4 to 206 responses only. I would like to also deprecate this message delimiting method as obsolete. chunked encoding fills the gap nicely.