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

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

From: John Franks <john@math.nwu.edu>
Date: Tue, 10 Jun 1997 17:27:37 -0500 (CDT)
To: Scott Lawrence <lawrence@agranat.com>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970610171447.20605A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3470
On Tue, 10 Jun 1997, Scott Lawrence wrote:

>   I never would have dreamed that this would generate so much heat.
> JF> Is there really evidence that this is a reasonable price to pay?
> JF> Are HTTP/1.0 POSTS so broken that this draconian measure is called
> JF> for?  I have not heard of any complaints from service providers
> JF> that HTTP/1.0 POSTS are a major problem.  Are there any such
> JF> complaints?
>   Not from a service provider, but from a server vendor.
>   I posted some discussion of this a while ago, which Henrik provided
>   a pointer to, but I'll repeat part of it now.
>   Our server provides the capability to use different access control
>   for serving vs. submitting a form.  This is handy in that the same
>   page can be used to display the current state of the server and to
>   modify it by changing something and submitting it.  Since the
>   submission may require new authentication, it _saves_ bandwidth if
>   the server can send the '401 Unauthorized' response before the POST
>   body has been sent.

It must be an *extremely* rare case that 1) a form requires
authentication, 2) the response requires authentication, and 3) the
authentication credentials for 1) and 2) are different!

Is it really worth adding an additional round trip to *every* POST
response to facilitate this?  There are some cases where 100 Continue
is "handy".  But they seem to be a tiny fraction of POST responses.
Can't we at least identify them in some way and not require 
"100 Continue" when it serves no function?

John Franks 	Dept of Math. Northwestern University
Received on Tuesday, 10 June 1997 15:32:28 UTC

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