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

Just a note from the Internet Printing Protocol working group, we are
planning on supporting pipelining
of PUT/POST in our initial version of the protocol...we would however be
supplementing any general
scheme such as those mentioned on the list with IPP-specific support for
pipelining.

Randy

Paul Leach wrote:

> > ----------
> > 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:32:16 UTC