- From: Joe Orton <jorton@btconnect.com>
- Date: Mon, 2 Jul 2001 15:29:44 +0100
- To: Steinar Bang <sb@metis.no>
- Cc: w3c-dist-auth@w3.org
On Mon, Jul 02, 2001 at 04:07:58PM +0200, Steinar Bang wrote: ... > 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 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) > > 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? 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 > there? Proxy servers are the big problem - they are mostly HTTP/1.0 compliant. Regards, joe
Received on Monday, 2 July 2001 10:36:11 UTC