- From: David W. Morris <dwm@xpasc.com>
- Date: Tue, 10 Jun 1997 17:28:45 -0700 (PDT)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: http-wg@cuckoo.hpl.hp.com
On Tue, 10 Jun 1997, Scott Lawrence wrote: > 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. > > Client Server > | | > >1 |-> GET /form.html HTTP/1.1 -------->| > | | > |<------------- HTTP/1.1 200 Ok <----| > | body contains form | > | | > >2 |-> POST /form.html HTTP/1.1 ------->| > | (no authorization, no body) | > | | > |<---- HTTP/1.1 401 Unauthorized <---| > | | > | | > >3 |-> POST /form.html HTTP/1.1 ------->| > | (with authorization) | > | | > |<------- HTTP/1.1 100 Continue <----| > | | > |-> (form data) -------------------->| > | | > |<------------- HTTP/1.1 200 Ok <----| > | ... | > > Request 1 is sent for a resource which contains a form, but which is > not protected by any realm. The resource is returned, and the > client has the opportunity to note that the server is 1.1. > > Request 2 is sent to post the form, but submission of the form is > protected by some realm, so this request is rejected. The server > can determine this before the request body is sent. > > Request 3 is the retry of 2 with authorization information; after > the headers are received, the server returns the 100 Continue to > indicate to the client that it is ok to proceed with the request > body. > > If the client had sent the form data immediately with Request 2, it > would have been just discarded by the server - a waste of time and > bandwidth, since the body must be resent with the authentication > data as part of request 3. > > JF> The proposed change seems likely to cause a dramatic degredation of > JF> service. I suspect that it will always be fairly rare for a server to > JF> reject a POST. Do we really have evidence that requiring 100 Continue > JF> for every POST is a good thing? > > Dramatic? What is the evidence for that? Well, my analysis is that a very small percentage of applications will be constructed in the manner you describe. Adding an extra RTT time for the 95%+ percent of the cases where it isn't needed seems pretty foolish. This is mitigated by the fact that if authentication is required, a relationship is implied between the user and the server. Since browsers tend to anticipate credential requirements it will often be the case that even the authenticated POST will not be rejected. AND in the cases where the browse can choose a reasonable delay waiting for the 100 CONTINUE, the saving of bandwidth by not sending extra data is minimal. When the bandwidth is critical, the RTT latency is too random to predict a reliable delay so the protocol complexity gains nothing. My intuition is also that this change to POST can cause a very bad degradation in perceived response time and actually open a larger window to network failures. Dave Morris
Received on Tuesday, 10 June 1997 17:34:08 UTC