Opened 15 years ago
Closed 12 years ago
#90 closed design (fixed)
Delimiting messages with multipart/byteranges
Reported by: | mnot@… | Owned by: | ylafon@… |
---|---|---|---|
Priority: | urgent | Milestone: | 11 |
Component: | p1-messaging | Severity: | Active WG Document |
Keywords: | Cc: |
Description
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?
Change History (16)
comment:1 Changed 15 years ago by mnot@…
comment:2 Changed 15 years ago by mnot@…
- Component set to auth
- Milestone set to unassigned
comment:3 Changed 15 years ago by mnot@…
- Component changed from auth to messaging
comment:4 Changed 14 years ago by mnot@…
- Milestone changed from unassigned to 07
- Severity set to Active WG Document
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.
comment:5 Changed 14 years ago by julian.reschke@…
- Milestone changed from 07 to 08
comment:6 Changed 14 years ago by mnot@…
- Priority set to urgent
comment:7 Changed 14 years ago by mnot@…
Discussed at Stockholm WG meeting; no objection to dropping as delimiter.
comment:8 Changed 13 years ago by julian.reschke@…
- Milestone changed from 08 to 09
comment:9 Changed 13 years ago by julian.reschke@…
- Milestone changed from 09 to 10
comment:10 Changed 13 years ago by julian.reschke@…
- Owner set to ylafon@…
comment:11 Changed 13 years ago by julian.reschke@…
- Milestone changed from 10 to 11
comment:12 Changed 13 years ago by 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).
comment:13 Changed 13 years ago by fielding@…
- Resolution set to incorporated
- Status changed from new to closed
I think this is completely incorporated in editor's draft.
comment:14 Changed 13 years ago by julian.reschke@…
comment:15 Changed 12 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:16 Changed 12 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
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.