* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #90 (closed design: fixed)

Opened 7 years ago

Last modified 4 years ago

Delimiting messages with multipart/byteranges

Reported by: mnot@pobox.com Owned by: ylafon@w3.org
Priority: urgent Milestone: 11
Component: p1-messaging Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/gmc0k3dm7les4il70mk2682vgapah8cqn1@hive.bjoern.hoehrmann.de

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

comment:1 Changed 7 years ago by mnot@pobox.com

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.

comment:2 Changed 7 years ago by mnot@pobox.com

  • Component set to auth
  • Milestone set to unassigned

comment:3 Changed 7 years ago by mnot@pobox.com

  • Component changed from auth to messaging

comment:4 Changed 5 years ago by mnot@pobox.com

  • Severity set to Active WG Document
  • Milestone changed from unassigned to 07

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 5 years ago by julian.reschke@gmx.de

  • Milestone changed from 07 to 08

comment:6 Changed 5 years ago by mnot@pobox.com

  • Priority set to urgent

comment:7 Changed 5 years ago by mnot@pobox.com

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

comment:8 Changed 5 years ago by julian.reschke@gmx.de

  • Milestone changed from 08 to 09

comment:9 Changed 5 years ago by julian.reschke@gmx.de

  • Milestone changed from 09 to 10

comment:10 Changed 5 years ago by julian.reschke@gmx.de

  • Owner set to ylafon@w3.org

comment:11 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 10 to 11

comment:12 Changed 4 years ago by fielding@gbiv.com

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 4 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated

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

comment:14 Changed 4 years ago by julian.reschke@gmx.de

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)

comment:15 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:16 Changed 4 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.