RE: ISSUE: MUST a client wait for 100 when doing PUT or POST re quests?

On Tue, 10 Jun 1997, Paul Leach wrote:

> > From: 	David W. Morris[SMTP:dwm@xpasc.com]
> > 
> > On Tue, 10 Jun 1997, Paul Leach wrote:
> > 
> > > This example only seems to require that the client wait for 100 if
> > it is
> > > pipelining -- otherwise it won't know which (possibly
> > non-idempotent)
> > > requests have or haven't been processed, which is a correctness
> > problem.
> > > Other scenarios show that efficiency might suffer if the client
> > didn't
> > > wait for a 100.
> > 
> > Seems to me that for correctness, it that is the issue, 100 CONTINUE
> > does not much for the problem.  The correctness issue CAN ONLY be
> > resolved
> > by the client waiting for the 200 OK after submitting the data.
> > 
> Waiting for 200 will tell you that the request was completed -- but the
> problem is that the request could have completed and the 200 tossed when
> the connection was reset. Or, to state it differently, the correctness
> issue the client can't know for sure when the request WASN'T processed
> and that it is safe to retry, and waiting for 200 doesn't solve that
> problem.

The client doesn't know for sure that something was or wasn't processed
based on the 100 CONTINUE. There is no additional assurance from the
100 CONTINUE over waiting for the 200 OK. If the client receives 100
CONTINUE it may eliminate some categories of rejects based on header
content but it can't know that the server didn't crash, or that the
connection wasn't lost before receiving a 4xx invalid request response
based on the transaction content.  Only actual receipt of the 200
is meaningful and a generic client MUST wait.  Some composite smart
clients may know that the POST/PUT is idempotent or have other 
mechanisms for recovering lost updates and be able to continue and
not wait for the 200 OK. But the samething applies to the 100 
CONTINUE.


> > In fact, if correctness is the issue, the 100 CONTINUE wait breaks
> > pipelining twice by requiring two waits instead of one.
> > 
> > I would go further and argue that it would be unusual to pipeline   
> > requests after the POST/PUT anyway.
> > 
> Noticing that is what led me to pose the original question. If PUT/POST
> with pipelining is the only bad (as opposed to inefficient) scenario,
> then the simplest solution might be to state that one should never
> pipeline PUT/POST.

Probably true in any case. As long as the NEVER is limited to those cases
that the client doesn't otherwise know it safe to not wait.

I think that combined with making the 100 CONTINUE an explicitly requested
optional response would provide the step wise operation which would
provide the efficiency when needed by assuring the client the ability to
expect the 100 CONTINUE but have no requirement for any server to always
response with 100 CONTINUE. I think a win-win.

I guess if I were perfect I would go and study the current RFC to learn
what is said about PUT/POST and 100 CONTINUE handling for proxies. All
I can envision is a really nasty can of snakes as a proxy implementor.


This really dicates that a proxy establish a thru path between its
server side connection to the client and its client side connection to
the down stream server. My unimplemented as of now design is more oriented
to being able to treat requests as autonomous things which are bundled up
and handed off to server connections and then re-assembled in the correct
order to return responses to the client.

A quick re-read of pieces of the RFC would lead me to the conclusion that
it is quite permissable for the PROXYSERVER to send an immediate
100 CONTINUE, gather the whole request and pass it on the the 
next server toward the origin.

A detail to straighten out at the very least.

Dave MOrris

Received on Tuesday, 10 June 1997 19:48:45 UTC