Delimiting messages with multipart/byteranges

[mnot@…]

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?

[mnot@…]

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.

[mnot@…]

Proposal is to drop multipart/byteranges as a delimiter completely, as it is believed that no implementation currently uses them in this manner, and the problems they present argue for not supporting them.

[mnot@…]

Discussed at Stockholm WG meeting; no objection to dropping as delimiter.

[fielding@…]

From [852]:

Changed message-body ABNF to be *OCTET. Specifying the actual number of octets will have to be done in prose.

Moved mistitled "Message Length" section into the Message Body section, since it only explains how many octets are in the body. Deleted useless "Entity Length" section and transfer-length term.

Addresses #28: Connection closing

Removed redundant mention of terminating by connection close and rewrote explanation so that it doesn't self-contradict.

Addresses #90: Delimiting messages with multipart/byteranges

Removed message-delimiting paragraphs of multipart/byteranges from p1 and p3.

Addresses #95: Handling multiple Content-Length headers

Added requirements for what to do if multiple or invalid Content-Length is received.

Rephrased requirements for Transfer-Encoding to only apply when a transfer-coding is present. Clarify that Transfer-Encoding overrides Content-Length and treat receiving both as an error. Clarify that only the chunked transfer-coding can delimit a message (the original design allowed other self-descriptive encodings, but that was abandoned in 2616).

Addresses #109: Clarify entity / representation / variant terminology

Entity-body terminology changed to payload in order to clarify that it is what gets packaged (as a message-body) into a message, allowing us to (eventually) distinguish between messages containing whole representations and messages containing only partial representations. Reduce use of the same terms for other things (e.g., in explanation of dates).

[fielding@…]

I think this is completely incorporated in editor's draft.

[julian.reschke@…]

From [859]:

Remove paragraphs in "changes from 2068" about message length handling that do not apply anymore after recent changes; update the remaining to not point to the other parts (see #90)(see #95)(see #109)