URL escaping - correct usage?

#1

I wish to construct a URL with properly escaped characters, with an optional query on the end.  I could do this with string operations and URL::addEscapeChars(), but I'm already passing URL objects around and I thought URL::toString() would do this for me.  Here's the problem:

If a URL object is constructed from a string, the URL constructor removes all escape chars after the query (?), but doesn't do anything with the main URL path (ie. everything before the query). 

Similarly, when a string is obtained using URL::toString(), the function adds escape chars to everything after the query but returns the main URL path as-is ie. without adding escape chars.

Since the URL path should be escaped too, my expectation is that it should get the same treatment as the query parameters.   What am I missing?

 

#2

Jules, any idea what's going on here?  Should URL escape/unescape the the main URL path as it does for the parameters?

#3

Not sure I understand the problem.. I didn't think it'd matter whether the path itself is properly escaped as long as the underlying OS calls can correctly resolve it. And if you really want to escape the string yourself for some purpose, then you can call addEscapeChars directly.

#4

It's mainly the inconsistency where everything after the '?' will be unescaped/escaped when it goes in/out of the URL class, but everything before the '?' isn't.  I've been writing some webDAV stuff where all the URLs must be correctly escaped, and I'd assumed that the URL class would automatically do that.

I can of course call URL::addEscapeChars(myURL.toString(true), true) to get a fully escaped URL with query.  This ends up escaping the (already escaped) query section, which should be harmless but led to my doubts about whether or not I'm using it properly, that's all.

#5

Fair point. Though I imagine that if I made it start escaping the URL now, it might be a problem for people who were relying on the current behaviour not to change the original string that they gave it.

#6

Equally fair point :)