Opened on Jan 16, 2014 at 5:08:07 PM
Closed on Jan 16, 2014 at 8:22:08 PM
Last modified on Jan 16, 2014 at 8:22:39 PM
#7739 closed defect (fixed)
PUT to directory with guest read permission results in zero length file
Reported by: | matthew bellew | Owned by: | dkocher |
---|---|---|---|
Priority: | normal | Milestone: | 4.4.4 |
Component: | webdav | Version: | 4.4.3 |
Severity: | normal | Keywords: | |
Cc: | Architecture: | ||
Platform: |
Description (last modified by dkocher)
Here's the scenario. guest has read access to a directory, but not write permission. The user (matthew) has write permission. Here is what I see on upload say a 100 byte file.
HEAD /myfile.txt (guest) 200 OK PUT /myfile.txt (guest, filesize=100) 401 Unauthorized PUT /myfile.txt (matthew, filesize=0) 200 OK
The HEAD is coming from DAVSession.login(). This succeeds and PUT tries to use the same credentials. When this fails, another PUT happens, but with 0 bytes (maybe the file pointer wasn't restored?).
My fix was to make my server return 401 on the HEAD command, but this requires user-agent snooping as HEAD can't return 401 to the browser. To fix authentication related weirdness in other client agent's I've made my server always require login for OPTIONS and PROPFIND. That has the advantage of only affecting WebDav clients, not normal HTTP usage.
I think there are two issues
a) the second PUT sends a zero-length file b) recommend maybe calling OPTIONS or PROPFIND in DavSession.login() since those are webdav specific methods rather than HEAD which the browser also calls.
Change History (2)
comment:1 Changed on Jan 16, 2014 at 8:22:08 PM by dkocher
- Milestone changed from 4.5 to 4.4.4
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed on Jan 16, 2014 at 8:22:39 PM by dkocher
- Description modified (diff)
- Summary changed from Webdav PUT to directory with guest read permission results in zero length file to PUT to directory with guest read permission results in zero length file
This should be fixed with the revert of a previous workaround in r14204.