- From: Steinar Bang <sb@metis.no>
- Date: Mon, 02 Jul 2001 16:17:16 +0200
- To: w3c-dist-auth@w3.org
>>>>> Steinar Bang <sb@metis.no>: >>>>> "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. I use libwww, so it looks like I may be using expect already: <http://www.w3.org/Library/src/HTTimer.html> From the logs it looks like the body may be sent twice where authentication is required, but that may be caused by the 2 sec timeout being too short for slow servers. The question is then, can I do the thing below...? > 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
Received on Monday, 2 July 2001 10:17:23 UTC