href in PROPFIND response question

[Evert | Rooftop]

Hey guys,

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.

So as for the question: should the href element be url-encoded or not?  
The spec doesn't explicitly seem to mention either way. I'm worried if  
I just plain remove this, clients might pick up '%-sequences' in href-
elements and wrongfully decode them.

Thanks,
Evert

[Werner Baumann]

Am Sat, 27 Jun 2009 20:19:05 -0400
schrieb Evert | Rooftop <evert@...>:

> 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.

> So as for the question: should the href element be url-encoded or
> not? The spec doesn't explicitly seem to mention either way. I'm
> worried if I just plain remove this, clients might pick up
> '%-sequences' in href- elements and wrongfully decode them.
>
Yes. % is the escape character and there is no way to run some kind of
mixed mode, sometimes treating it as escape character sometimes not.

The spec *seems* to be not clear about this but this is only because it
references other specs about URIs.

> RFC 4918, 8.3.1 Example - Correct URL Handling:
> [...]
>   * '/sample/' and '/sample/a%20test'
> Note that even though the server may be storing the member resource
> internally as 'a test', it has to be percent-encoded when used inside
> a URI reference (see Section 2.1 of [RFC3986]). Also note that a legal
> URI may still contain characters that need to be escaped within XML
> character data, such as the ampersand character.

Werner

[Evert | Rooftop]

On 28-Jun-09, at 4:29 AM, Werner Baumann wrote:

> Am Sat, 27 Jun 2009 20:19:05 -0400
> schrieb Evert | Rooftop <evert@...>:
>
>> 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.

Evert