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

> ----------
> From: 	David W. Morris[SMTP:dwm@xpasc.com]
> Sent: 	Tuesday, June 10, 1997 6:58 PM
> To: 	Paul Leach
> Cc: 	John Franks; 'frystyk@w3.org'; http-wg@cuckoo.hpl.hp.com;
> lawrence@agranat.com; rlgray@raleigh.ibm.com
> Subject: 	RE: ISSUE: MUST a client wait for 100 when doing PUT or
> POST   re quests?
> 
> 
> 
> 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.
>  
> 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.
>  
Paul

Received on Tuesday, 10 June 1997 19:09:52 UTC