Subject: mistake in section 8.1.2 of RFC2616?

From: Pierre Phaneuf <[email-masked]>
Date: Wed, 30 Apr 2003 10:45:48 -0400 (EDT)

(I'm not on the mailing list, please Cc me!)

In section 8.1.2, you can read the following:

> Once a close has been signaled, the client MUST NOT send any more
> requests on that connection.

Is it just me, or that "MUST NOT" would forbid pipelining? A pipelining 
client MAY send more requests, but they will be ignored by the server 
and it should be prepared to that possibility (section 8.1.2.2 mentions 
that a client MUST be prepared to the server closing the connection 
before it handled them all).

Thanks!

-- 
Pierre Phaneuf
Mad Scientist, NITI R&D

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 30 Apr 2003 10:41:41 -0600 (MDT)

> before it handled them all).

This is not meant to prevent pipelining. In this context, you should
interpret the above RFC wording as "once the close signal has been
received by the client, the client MUST NOT send any more requests on
that connection." as opposed to your current interpretation of "once
the close signal has been sent by the server, the client ..."

HTH,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: Pierre Phaneuf <[email-masked]>
Date: Wed, 30 Apr 2003 12:50:00 -0400 (EDT)

Alex Rousskov wrote:

>> Is it just me, or that "MUST NOT" would forbid pipelining? A
>> pipelining client MAY send more requests, but they will be ignored
>> by the server and it should be prepared to that possibility
>> (section 8.1.2.2 mentions that a client MUST be prepared to the
>> server closing the connection before it handled them all).
> 

I know that this is the spirit of the document, but maybe it should be 
clarified in the errata.

I also suspect that it could be fine sending more requests to the server 
in a simplistic client implementation, since they will be harmlessly 
ignored by the server, but on the other hand, this requires being ready 
to re-send those requests, so while you're at it, better do it right.

Thank you!

-- 
Pierre Phaneuf
Mad Scientist, NITI R&D

---

From: Scott Lawrence <[email-masked]>
Date: 30 Apr 2003 12:57:13 -0400

Pierre Phaneuf <[email-masked]> writes:

> client MAY send more requests, but they will be ignored by the server and
> it should be prepared to that possibility (section 8.1.2.2 mentions that a
> client MUST be prepared to the server closing the connection before it
> handled them all).

It doesn't forbid it, but it makes some additional work for the
client: 

  8.1.2.2 Pipelining

     [...] Clients MUST also be prepared to resend their requests if
     the server closes the connection before sending all of the
     corresponding responses.

-- 
Scott Lawrence        
  Actively seeking work 
  http://skrb.org/scott/
  [ <[email-masked]> is deprecated ]

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 30 Apr 2003 11:11:55 -0600 (MDT)

On Wed, 30 Apr 2003, Pierre Phaneuf wrote:

> I know that this is the spirit of the document, but maybe it should
> be clarified in the errata.

Perhaps. Although if we get that picky, the errata will get longer
than the RFC itself :-).

> I also suspect that it could be fine sending more requests to the
> server in a simplistic client implementation, since they will be
> harmlessly ignored by the server, but on the other hand, this
> requires being ready to re-send those requests, so while you're at
> it, better do it right.

Depends on your definition of "fine", I guess. The client will be
wasting bandwidth and other resources. The server HTTP stack is indeed
likely to see no "extra" requests after the TCP connection is closed
(which usually happens right after the final server response is sent).
However, asynchronous I/Os, half-closed TCP connections, SSL/TLS
wrappers, and other real-world complications make the situation less
predictable.

As for re-sending pipelined requests, we already have a MUST for that:

   Clients MUST also be prepared to resend their requests if
   the server closes the connection before sending all of the
   corresponding responses.

Alex.