RE: WebDAV and write access discovery

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