- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 2 Jul 2001 11:08:28 -0400
- To: w3c-dist-auth@w3.org
You are not allowed to send a Expect request header if you do not intend to send a request body (Section 8.2.3): A client MUST NOT send an Expect request-header field (section 14.20) with the "100-continue" expectation if it does not intend to send a request body. An early terminated PUT request (i.e. without a message body) should be treated by the server as a failure by the client, and not as a 0-length content update. But the overhead of having the client prematurely terminate a connection (to get the PUT to fail) or wait for the server to timeout the connection, would make it unadvisable to use this as a techique for finding out whether the resource is readonly. When the ACL protocol is implemented, that would be the best way to determine whether a resource is readonly. If it is a Class 2 DAV server, trying to get a write lock might be something to try, but I don't know whether or not servers tend to fail requests to get write-locks on read-only resources. Cheers, Geoff -----Original Message----- From: Steinar Bang [mailto:sb@metis.no] Sent: Monday, July 02, 2001 10:08 AM To: w3c-dist-auth@w3.org Subject: Re: WebDAV and write access discovery >>>>> "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 11:02:01 UTC