Subject: Re: WebDAV and write access discovery

From: Steinar Bang <[email-masked]>
Date: Mon, 02 Jul 2001 16:07:58 +0200

>>>>> "Clemm, Geoff" <[email-masked]>:

> 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?

---

From: Steinar Bang <[email-masked]>
Date: Mon, 02 Jul 2001 16:17:16 +0200

>>>>> Steinar Bang <[email-masked]>:

>> before you've sent the request body (an ACL violation is only one
>> of the reasons why the request might fail).

> 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...?

---

From: Joe Orton <[email-masked]>
Date: Mon, 2 Jul 2001 15:29:44 +0100

On Mon, Jul 02, 2001 at 04:07:58PM +0200, Steinar Bang wrote:
...
> overwritten with a file of 0 bytes?

The behaviour will be server-dependent I expect. (at least, since the
RFC doesn't cover this case, you can't rely on any particular behaviour)

> with an empty request body, and the file get 0 bytes?

The problem is that HTTP/1.0 servers ignore the extension, so both
client and server block waiting for the other.

> Is this a real risk?  Are there any PUT enabled HTTP/1.0 servers out

Proxy servers are the big problem - they are mostly HTTP/1.0 compliant.

Regards,

joe