W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: Pipelining in HTTP 1.1

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 30 Mar 2009 17:05:03 -0700
Message-Id: <71E52375-E8D5-42AC-BCB7-B6017A29FF8C@gbiv.com>
Cc: <ietf-http-wg@w3.org>, "Jonathan Leighton" <leighton@cis.udel.edu>, "Paul D. Amer" <amer@cis.udel.edu>, "Fred Baker (fred)" <fred@cisco.com>
To: Preethi Natarajan (prenatar) <prenatar@cisco.com>
On Mar 30, 2009, at 2:27 PM, Preethi Natarajan (prenatar) wrote:
> I would like your comments on the following. This is w.r.t. HTTP  
> over SCTP (draft-natarajan-http-over-sctp-01) and I am trying to  
> comprehend "pipelining" in the context of HTTP 1.1.
> From Section of RFC2616:
> "A client that supports persistent connections MAY "pipeline" its  
> requests (i.e., send multiple requests without waiting for each  
> response). A server MUST send its responses to those requests in  
> the same order that the requests were received."
> We (SCTP folks) assume that "persistent connection" in this section  
> refers to a persistent _transport_connection. When multiple HTTP  
> requests and responses are sent back-to-back on a persistent  
> transport connection, the HTTP transactions are pipelined.

Yes; we already plan on making that clear in HTTPbis part 1.
This requirement should be just a statement that responses are
associated to requests by their order in an otherwise untagged
stream.  Other transport protocols might supply their own
mechanism for request-response association, or even extend HTTP
such that the request/response contains some form of matching ID.

> In our HTTP over SCTP streams design, we recommend transmitting  
> HTTP requests/responses over different SCTP streams, but note that  
> these reqeusts/responses are transmitted back-to-back within an  
> SCTP transport connection. I.e., the HTTP transactions are  
> pipelined across multiple streams of an SCTP transport connection  
> but are not pipelined within an SCTP stream. I am tempted to say  
> that this design still confirms to the "pipelining" definition as  
> per RFC2616.

I don't think you will need to worry about such conformance
except in the case where a TCP connection stream of pipelined
requests is being proxied to a set of SCTP streams.  In that case,
there is an implied expectation of ordering on the client regarding
state-changing requests that must be respected by the proxy.

The user agent needs to be in control of the order in which some
requests are handled by the origin server when there exists a
state-changing (unsafe) method in the stream because it is common
for a user agent to modify a resource and then immediately request
the resulting representation as it should appear after the modification
has been applied.  It would be annoying if that GET was reordered by
the SCTP proxy such that it was handled before the modification.

A transport change like SCTP is free to multiplex any sequence of
safe (GET/HEAD/OPTIONS/...) requests however it likes, assuming that it
has some way of re-associating the request-response pair, but it must
wait until each of the previous requests have received at least a
response status prior to initiating an unsafe request
(PUT/PATCH/DELETE/POST/...) from the same source.

I am somewhat surprised that your HTTP over SCTP spec allows channels
to be reused.  Is there a significant cost associated with channel
allocation?  TCP persistent connections added a huge amount of
complexity and fairness/denial-of-service issues to HTTP servers
just to avoid the side-effects of TCP slow-start and connection
negotiation.  I was hoping that an SCTP channel could be handled
in a send-and-forget mode, since that is more efficient for servers
that aren't designed around event handlers.
Does the sctp_sendmsg/sctp_recvmsg API solve those problems?

Received on Tuesday, 31 March 2009 00:05:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:48 UTC