- From: Preethi Natarajan (prenatar) <prenatar@cisco.com>
- Date: Mon, 30 Mar 2009 18:39:13 -0400
- To: "David Morris" <dwm@xpasc.com>, <ietf-http-wg@w3.org>
- Cc: "Fred Baker (fred)" <fred@cisco.com>, "Jonathan Leighton" <leighton@cis.udel.edu>, "Paul D. Amer" <amer@cis.udel.edu>
> -----Original Message----- > From: ietf-http-wg-request@w3.org > [mailto:ietf-http-wg-request@w3.org] On Behalf Of David Morris > Sent: Monday, March 30, 2009 3:05 PM > To: ietf-http-wg@w3.org > Cc: ietf-http-wg@w3.org > Subject: Re: Pipelining in HTTP 1.1 > > > Use caution for anything which might re-order processing of > transactions which are not idempotent. Pipelining includes > some rules regarding waiting for responses in those cases. I > think you are attempting to mix apples and oranges and are > going to confuse the reader. If I understand SCTP correctly, > each SCTP stream is equivalent to a unique TCP connection in > terms of packet flow management. So your different streams > is equivalent to multiple connections under classic HTTP/TCP. > That being the case, HTTP pipelining rules and discussion > applies to each individual SCTP stream and anything below > that layer shouldn't be considered by HTTP. > > Pipelining retains the order of requests within a TCP > connection. Again per my understanding SCTP retains the order > within the SCTP stream but not between streams so to compare > behavior at the SCTP transport level with behavior at the TCP > connection level makes no sense to me. > Your understanding of SCTP streams is accurate. What you are saying confirms my earlier suspicions that the "pipelining" section in 2616 actually defines "pipelining over TCP" and not "pipelining over a transport connection". I suppose a spec describing HTTP over SCTP should accurately define "pipelining over SCTP streams" and discuss how it relates to 2616. Thanks, Preethi
Received on Monday, 30 March 2009 22:39:55 UTC