Subject: RE: On pipelining -Reply

From: Miles Sabin <[email-masked]>
Date: Fri, 21 Jan 2000 17:39:55 -0000

Christopher K. St. John wrote,
> SHOULD (in the rfc2119 sense) is unfortunately the operative
> word here. GET's idempotence is a SHOULD, not a MUST. 
> Reference rfc2616, section 9.1.1. 

Not at all. I don't see anything there, or anywhere else, which
states that GETs idempotence is optional.

All it says is that GET "SHOULD NOT have any significance other 
than retreival". That's a *very* long way from permitting side-
effects. It allows but discourages, for example, a server
making a rude noise when it handles a GET ... but that's not 
state.

Cheers,

Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
[email-masked]          http://www.cromwellmedia.com/

---

From: "Christopher K. St. John" <[email-masked]>
Date: Fri, 21 Jan 2000 12:22:03 -0600

> states that GETs idempotence is optional.

 From section 9.1.1:

     "Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in
   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them."

 However, from section 9.1.2:

    "Methods can also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property."

 Which, as I read it, says you are free to have GET requests change
server side state as long as the state changes are idempotent. (Although
9.1.1's language can easily be read as weakening that considerably)

> making a rude noise when it handles a GET ... but that's not

 So, a compliant implementation may have idempotent side effects,
but an unconditionally compliant implementation may not.

 Unfortunately, my experience with servlets and other application server
technologies leads me to believe that the "idempotent" requirement for
side effects is widely ignored (and not just for page counters) Not that
that's an excuse, just a data point :-)

 Thanks for the clarification,

-cks

---

From: Tim Chao <[email-masked]>
Date: Sun, 23 Jan 2000 09:54:06 -0800

1.  I looked into several captured packets of a HTTP request,
     there are lots of "OD OA" as deviders for headers;
     sometimes a request ends with "OD 0A 0D 0A", sometimes ends
      with "0A 0A 0A" or ....
     In the RFC, the request can end with 0D or 0A or their combination,

     I wonder how does a HTTP server or HTTP client determines
     a full request is received?.  Shouldn't we have a better way to
determine
     it?

2.   When a user is using a Web browser , the "Reload" in netscape
       or the"Refresh" in IE is pressed, what's the policy the browser
       to use about when to start with a new connection( SYN issued
first).
       or to start with just a HTTP request( ACK push)?

Many thanks!

---

From: [email-masked] (Koen Holtman)
Date: Wed, 26 Jan 2000 12:24:36 +0100 (MET)

>       or to start with just a HTTP request( ACK push)?

There are no TCP/IP level or connection level policies implied as far
as I know.  The implied policy is to get the page again, and get a
copy fresh from the origin server, without any intermediate cached
copy being used instead.  This implies that a new HTTP request has to be
sent, but not necessarily that an existing persistent connection has
to be broken.

Hope this helps,

Koen.