W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2009

Re: href in PROPFIND response question

From: Evert | Rooftop <evert@rooftopsolutions.nl>
Date: Sun, 28 Jun 2009 12:12:38 -0400
Cc: w3c-dist-auth@w3.org
Message-Id: <F82EED28-C543-4F90-8110-EBE2AFA535DC@rooftopsolutions.nl>
To: Werner Baumann <werner.baumann@onlinehome.de>
On 28-Jun-09, at 4:29 AM, Werner Baumann wrote:

> Am Sat, 27 Jun 2009 20:19:05 -0400
> schrieb Evert | Rooftop <evert@rooftopsolutions.nl>:
>> I have had a user reporting a bug in my WebDAV server library. To
>> keep things short, I currently url-encode every segment in the
>> href-element within propfind responses.
>> This has thus far worked for everyone, except this user (who
>> reported to use Git as a client). After removing the url-encoding of
>> the contents of the href element, things started working fine.
> Your server was right and the client is broken. Please don't change  
> the
> server behaviour, because it would break conforming clients like e.g.
> Neon. I have got a report from a user of davfs2 where exactly this
> happens. The server sends href-elements like
> <d:href>/documents/tier2/BOARD%20AND%20CTTE%20DOCS/Board
> Meetings/</d:href>
> which can not be decoded by Neon. (Note: there is an unencoded space
> character between 'Board' and 'Meetings'.)
> Fixing the broken applications is the only way that will work. Trying
> to work around this kind of bugs would only increase the confusion and
> create more interoperability problems.

Thanks for the concise answer, I'll see if I can get the user to file  
a bug report.

Received on Sunday, 28 June 2009 16:13:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:43 UTC