Re: Pipelining in HTTP 1.1

I personally would agree with your viewpoint, with one caveat. The  
language of 2616 is clearly oriented towards TCP as a transport. In  
SCTP, you are doing the spirit of the recommendation with a different  
transport, which has a difference in effect - the requirement is not  
that the order of the responses must be the same as the order of the  
requests, but that the responses must be within the streams that the  
requests came in.

On Mar 30, 2009, at 2:27 PM, Preethi Natarajan (prenatar) wrote:

> Hello folks,
>
> 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 8.1.2.2 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.
>
> 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.
>
> Thoughts?
> Preethi
>
>