On 22 Oct 2013, at 16:07, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 22 Oct 2013, at 15:49, "phil@highoctane.be" <phil@highoctane.be> wrote:
I'd say you can encode @ with % in the URL (but it is not needed in any case) indeed but in the rendered output? (Do you mean in hrefs="xxx" ?)
Some things must be encoded indeed:
http://en.wikipedia.org/wiki/Character_entity_reference http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_reference... http://www.w3schools.com/tags/ref_urlencode.asp
As '@' is in the ASCII set, why should it be encoded?
Because that is what the spec says:
http://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters
These characters,
! * ' ( ) ; : @ & = + $ , / ? # [ ]
have to be percent encoded in external (printed) representations of URLs, ASCII or not.
This has nothing to do with HTML or XML.
ZnPercentEncoder uses the following
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 - _ . ~
as its safe set (characters that do not have to be encoded), just like the spec says.
I could be wrong, but I don't think so.
Well, the finer point is of course <quote> When a character from the reserved set (a "reserved character") has special meaning (a "reserved purpose") in a certain context, and a URI scheme says that it is necessary to use that character for some other purpose, then the character must be percent-encoded. </quote> and <quote> Reserved characters that have no reserved purpose in a particular context may also be percent-encoded but are not semantically different from those that are not. In the "query" component of a URI (the part after a ? character), for example, "/" is still considered a reserved character but it normally has no reserved purpose, unless a particular URI scheme says otherwise. The character does not need to be percent-encoded when it has no reserved purpose. </quote> So in each context (scheme, url part) it might be slightly different. ZnPercentEncoder takes the better safe than sorry route.
Sven
URL Encoding of @ is %40 indeed but digits also have encodings. Not a reason to use them :-)
I'd say that the issue is in ZnClient, basically defaulting to a capability that is linked to server interpretation of URLs. There is no reason why the URL you use must be associated with authentication, only that mainstream servers can do that with mod_auth or something.
Other than that it is just a pathinfo string.
A ZnClient option saying 'enableAuthority:' maybe? I do not think that a better parsing of options would solve the situation as someone may want to have the same scheme but for other purposes.
Phil