W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: 1xx Clarification

From: John Franks <john@math.nwu.edu>
Date: Mon, 21 Apr 1997 14:45:56 -0500 (CDT)
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970421141802.10754B-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3108
On Mon, 21 Apr 1997, Jeffrey Mogul wrote:

> John Franks <john@math.nwu.edu> writes:
>     I haven't been following the "100 Continue" discussion, but today I
>     read all the relevant sections of the spec and I must say I am 
>     confused.
> You might also want to read 
> 	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q2/0134.html
> which is my attempt to explain the motivation behind the design.

Thanks Jeff.  This is indeed very helpful and explains much of what I
wanted to know.  The specification needs to be at least as clear as

I now am of the opinion that the benefits of "100 Continue" are not
worth the added complexity.  Or at least the burden of proof should be
shifted to the proponents to explain why this is worth it.  Even
though the internet is crowded simplicity and robustness must take
precedence over efficiency.

I am also troubled by the part of the specification which says,

   "If the client does retry the request to this HTTP/1.0 server, it
   should use the following "binary exponential backoff" algorithm to be
   assured of obtaining a reliable response:"

Is the "should" here different from SHOULD?  I don't think this level
of implementaion detail exists elsewhere in the spec.  Is there a
rationale for having it here (as opposed to putting it with other
implementation notes)?

> My understanding is that the client initially (i.e., the first
> time it sends a request-with-body to a given server) does not wait.
> But once it has seen the server close the connection "prematurely"
> and it retries the request, it MUST wait, at least for that request.
> The spec is silent on whether it is then mandatory for the client
> to use the two-phase approach for a subsequent request-with-body.
> I believe that this is not mandatory from a logical standpoint
> (i.e., the protocol won't deadlock) but it might be necessary
> from an efficiency standpoint (i.e., there could be a lot of
> retrying otherwise).  But, again, I think the whole two-phase
> approach is of dubious merit, given its complexity.

This needs to be clarified and put in the specification unless we
can discard "100 Continue".

John Franks 	Dept of Math. Northwestern University
Received on Monday, 21 April 1997 12:52:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC