Opened 8 years ago

Closed 8 years ago

#283 closed design (fixed)

Set expectations around buffering

Reported by: mnot@… Owned by: julian.reschke@…
Priority: normal Milestone: 15
Component: p1-messaging Severity: Active WG Document
Keywords: Cc:

Description

People are alternatively shocked and angry that HTTP intermediaries can and do buffer request and response messages. There should be some text that introduces people to this, and perhaps places some expectations around it.

Probably belongs in "HTTP-related architecture" and/or "Message Transmission Requirements."

Attachments (1)

283.diff (1.8 KB) - added by julian.reschke@… 8 years ago.
proposed new subsection for section 2

Download all attachments as: .zip

Change History (9)

comment:1 Changed 8 years ago by mnot@…

Suggestion from Willy at the end of p1-3.3 "Message Body" :

Implementations MUST NOT rely on the ability to receive an incomplete message body. Full or partial message buffering by intermediaries or application servers, as well as re-chunking MAY impact user experience (eg: progress bar sent at once, or streamed video starting when fully transferred), but MUST NOT break the intended use. As such, applications MUST NOT expect bessage bodies to be usable as a bidirectional stream over which conversations are interleaved between the user-agent and the origin server.

comment:2 Changed 8 years ago by mnot@…

Proposal for a new section after 2.1 Client/Server? Messaging

2.2 Message Orientation and Buffering

Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked [ref to chunked encoding] and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide other services.

Therefore, extensions to and uses of HTTP cannot rely on the availability of a partial message, or assume that messages will not be buffered. There are strategies that can be used to test for buffering in a given connection, but it should be understood that behaviours can differ across connections, and between requests and responses.

... with a reference to the new section somewhere in 7.2. Message Transmission Requirements.

comment:3 Changed 8 years ago by mnot@…

  • Milestone changed from unassigned to 15

comment:4 Changed 8 years ago by julian.reschke@…

  • Owner set to julian.reschke@…
  • Status changed from new to assigned

Changed 8 years ago by julian.reschke@…

proposed new subsection for section 2

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

From [1316]:

set expectatiions around buffering (see #283)

comment:6 Changed 8 years ago by julian.reschke@…

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

comment:7 Changed 8 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:8 Changed 8 years ago by mnot@…

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