Summary | Add browse API call to implement WebDAV read support |
Queue | Gollem |
Queue Version | HEAD |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | jan (at) horde (dot) org |
Requester | bklang (at) horde (dot) org |
Created | 05/07/2007 (6629 days ago) |
Due | |
Updated | 06/26/2007 (6579 days ago) |
Assigned | 05/08/2007 (6628 days ago) |
Resolved | 06/26/2007 (6579 days ago) |
Milestone | |
Patch | Yes |
State ⇒ Resolved
State ⇒ Assigned
New Attachment: gollem-browse-v3.patch
When browsing using Mac's Finder as the WebDAV client, the folder is
presented in the UI with '+' instead of a space. Thus, %20 is required.
I have changed the function to call rawurlencode().
counterparts, so that
you won't have to encode spaces aka + separately. Btw, why you do you need to
encode them anyway?
On second thought, it is possible that the "+" to "%20" modification
is not required. I think when I wrote that function I had not yet
discovered the bug in HTTP_WebDAV_Server and so I was
overcompensating. I will take out that line and test.
do not think I see how it would save me any calls? Would you give me
another hint?
counterparts, so that you won't have to encode spaces aka +
separately. Btw, why you do you need to encode them anyway?
New Attachment: gollem-browse-v2.patch
double for gettext.
I checked the documentation on rawurlencode() vs. urlencode() but I do
not think I see how it would save me any calls? Would you give me
another hint?
State ⇒ Feedback
save one str_replace() call by using rawurlencode() instead of
urlencode().
Priority ⇒ 1. Low
State ⇒ New
New Attachment: gollem-browse.patch
Queue ⇒ Gollem
Summary ⇒ Add browse API call to implement WebDAV read support
Type ⇒ Enhancement
browsing Gollem/VFS shares via WebDAV. Two additional supporting
functions are added to the Gollem:: class. If this patch is merged I
will also implement the _gollem_put() method to complete WebDAV
support (and I believe close a bounty in the process).
Note that there is a bug in HTTP_WebDAV_Server which affects any
filename containing "+", "%" or any other filename with urlencoded
characters. A bug has been filed upstream. Even without this fixed,
all files and directories without special characters are handled
properly.