- 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
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 john@math.nwu.edu
Received on Tuesday, 10 June 1997 15:32:28 UTC