On Sat, Jan 24, 2004 at 12:48:33AM +0100, André Malo wrote:
* Greg Stein <[EMAIL PROTECTED]> wrote:
On Fri, Jan 23, 2004 at 11:28:28PM +0100, André Malo wrote:
Hmm, and then? I'd see it as a workaround for buggy clients like the "redirect-carefully" variable.
It's a matter of degree. Just how many clients are broken, and what percentage of traffic do they represent? The redirect-carefully was put in because of a great many, popular clients were borken.
Dunno ;-) How many clients are we talking about?
Redirect-Carefully IMHO affects all Microsoft Webfolder clients. Maybe this needs to be added to the (webfolder) issues list?
Julian Reschke's bug-tracker lists the versions of the MS clients this is known to affect: (that doesn't really answer the question, I know)
http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-hashmark-escaping
As I understand it, the clients only screw up when hash is the first character of the last path segment: is that right Julian? I'd consider it a relatively obscure issue, it's not worth putting a lot of effort into other than making sure the requests are rejected.
If the hashmark is the first character of a path segment, buggy servers will apply the request to the parent collection instead of just rejecting the request (it's not a valid request according to RFC2616). This is of course a desaster for DELETE.
On the other hand, if the hashmark isn't the first character, the request may get applied to the resource identified by the path segment truncated at the "#". So, you may want to delete "a%23b", but what get's deleted is "a". Still a major problem.
So there are (were) two issues: a client (Webfolder) that didn't escape the hashmark (only a few releases, and I think this issue is resolved in later clients), and a server that doesn't (didn't?) reject invalid requests.
Hope this helps.
Julian
P.S.: The issue list mentioned above depends on people contributing empirical data. Hint, hint. :-)
-- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
