- 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
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 this. 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 john@math.nwu.edu
Received on Monday, 21 April 1997 12:52:20 UTC