Re: Possible WebDAV bug?
Re: Possible WebDAV bug?
- Subject: Re: Possible WebDAV bug?
- From: Jim Luther <email@hidden>
- Date: Wed, 25 Feb 2009 18:42:40 -0800
When the WebDAV file system gets an open() request for a file the
first time, it starts a GET of the file's resource and saves the data
from the GET into a local cache file. Read and write file system
requests are handled from that local cache file. If the file is closed
before the GET is complete, we kill the connection and close the local
cache file with whatever data has already been downloaded. If the file
is re-opened, we will start a new GET where the last left off passing
a Range: bytes=XXXXX- header where "XXXXX" is the where we want to
resume the GET (the byte after the last we previously downloaded) and
passing a If-Range: date header with the date from Last-Modified
response header the previous GET returned. We'll either receive a 206
response (which tells us the cache file is still valid) with the
remainder of the file which we append to the data already received, or
a 200 response which tells us the resource on the server changed and
we're getting the whole resource again. That's what you are seeing --
a GET being resumed when a file is reopened that wasn't completely
downloaded the last time it was open.
If a previously opened file was completely downloaded, a reopen will
send a GET with a If-Modified-Since: date header. We'll either receive
a 304 (not modified) response which tells us the cache file is still
valid, or a 200 response which tells us the resource changed and we're
getting the whole resource again.
The other, more unusual, case you might see is a GET with a Range
header while the main GET started by the open() is still in progress.
That will happen if we get a small read() request (where small is less
than 8K) for a part of the file that hasn't yet been downloaded and
the read() starts more than 32K from the current EOF of the local
cache file. In this case, the GET's Range header will have both a
start and an end. We do this so that small reads don't block for
possibly long periods of time waiting for data the server probably
hasn't even sent yet.
So, there's no bug... you're just seeing how the WebDAV file system
attempts to handle file system requests with the fewest number of HTTP/
WebDAV requests.
Hope that helps :-)
- Jim (I haven't worked on the WebDAV file system since Tiger) Luther
On Feb 25, 2009, at 4:14 PM, Evert|Rooftop wrote:
Dear list,
I'm in the process of writing a WebDAV server implementation. Things
are going well, but I recently added the HTTP Content-Range features
which led me to find a strange bug.
As I'm browsing my webdav volume, preview icons no longer appear in
Finder. I noticed using an HTTP Debugging proxy Finder will ask for
byte ranges, such as :
Range: bytes=23403-
to which I respond:
Content-Range:23403-28518/28519
Content-Length: 5116
First off, it seems odd that finder seems to request a seamingly
random number of bytes from the bottom of the file. I can't really
detect a pattern in the number of bytes requested vs. the actual
size of the file.
Could this be a Finder bug? Is there a better place to pose this
question?
Evert
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden