- From: Steinar Bang <sb@metis.no>
- Date: Mon, 02 Jul 2001 16:07:58 +0200
- To: w3c-dist-auth@w3.org
>>>>> "Clemm, Geoff" <gclemm@rational.com>: > Probably the most general way to handle this is with the Expect > header ... that lets the server tell you that the request will fail > before you've sent the request body (an ACL violation is only one of > the reasons why the request might fail). Thanx for the tip. Quick reference for other uninitiated: <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20> Basically, if I've understood section 8.2.3 on how to handle the 100-continue response to an expect request (link at the end of the above section), the client should not send the body of the message until it sees a "100 continue" response to the server. So that would avoid me having to send the body over twice, in the case of authentication of a PUT request, which is great. One thing I would like to do, is to find out if a file is writable when I load it. Ie. I would like to do something like: - GET a file - immediately start a PUT of the file with the expect header in place - if I get a "100 continue" response, set the file to be R/W, otherwise mark it as read-only However, in this case the client has no intention of actually sending the body, even if the server returns a "100 continue", and I'm unsure of what happens if it doesn't? Will the 1.1 pipeline be blocked? Will a new request be taken to be an empty PUT body, and the file be overwritten with a file of 0 bytes? > The main problem with the Expect header is that it is an HTTP/1.1 > construct that is not understood by old HTTP/1.0 servers and > proxies. What's the risk with HTTP/1.0 servers in my case? That the PUT request with an expect header will be taken as an actual PUT request with an empty request body, and the file get 0 bytes? Is this a real risk? Are there any PUT enabled HTTP/1.0 servers out there?
Received on Monday, 2 July 2001 10:08:11 UTC