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

Ticket #283 (closed design: fixed)

Opened 3 years ago

Last modified 3 years ago

Set expectations around buffering

Reported by: mnot@pobox.com Owned by: julian.reschke@gmx.de
Priority: normal Milestone: 15
Component: p1-messaging Severity: Active WG Document
Keywords: Cc:
Origin:

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

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

Change History

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

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 3 years ago by mnot@pobox.com

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 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 15

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

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

Changed 3 years ago by julian.reschke@gmx.de

proposed new subsection for section 2

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

From [1316]:

set expectatiions around buffering (see #283)

comment:6 Changed 3 years ago by julian.reschke@gmx.de

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

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

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

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