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 10:08:11 UTC