Zinc: How to use the @ character in an URL

> The solution must be to modify the method ZnUrl>>#parseAuthority:from:to: to do a better detection of authentication pattern:
>
> parseAuthority: string from: start to: stop
> | index  |
>
> index := string indexOf: $@ startingAt: start.
>
> (index > 0 and: [ (string indexOf: $: startingAt: start) < index and: [ index < (string indexOf: $/ startingAt: start) ] ])
> ifTrue: [  
> self parseUserInfo: (ReadStream on: string from: start to: index - 1).
> self parseHostPort: (ReadStream on: string from: index   1 to: stop )
> ]
> ifFalse: [  self parseHostPort: (ReadStream on: string from: start to: stop ) ]

> Hi Olivier,
>
> On 22 Oct 2013, at 09:57, Olivier Auverlot <[hidden email]> wrote:
>
>> Hi,
>>
>> I work actually on a framework to manage a Proxmox server. The Proxmox solution is based on a strange REST API… :-(
>>
>> To get informations about an user, I must send a string with the login and the authentication domain. The two values are separated by a character @.
>>
>> For example: GET /api2/extjs/access/users/auverlot@LIFL
>>
>> My first problem with Zinc is that the client find the character @ and the client think that this is an URL with authentication. I tried to use an encoding string with %40 but Proxmox don't find the user.
>
> According to http://en.wikipedia.org/wiki/Urlencoding and thus http://tools.ietf.org/html/rfc3986 which is the URI spec, @ is a reserved character and has to be encoded. Which means that both as input for parsing as well as in rendered output it should be percent encoded, at least that is how I understand it.
>
> Do you have a different opinion ?
>
> Can you make the REST call using curl ?
>
>> The solution must be to modify the method ZnUrl>>#parseAuthority:from:to: to do a better detection of authentication pattern:
>>
>> parseAuthority: string from: start to: stop
>> | index  |
>>
>> index := string indexOf: $@ startingAt: start.
>>
>> (index > 0 and: [ (string indexOf: $: startingAt: start) < index and: [ index < (string indexOf: $/ startingAt: start) ] ])
>> ifTrue: [  
>> self parseUserInfo: (ReadStream on: string from: start to: index - 1).
>> self parseHostPort: (ReadStream on: string from: index   1 to: stop )
>> ]
>> ifFalse: [  self parseHostPort: (ReadStream on: string from: start to: stop ) ]
>
> I am not convinced (yet) that the parser have to change.
>
> I guess one hack could be to subclass ZnUrl and overwrite #encode:on: to use a customised ZnPercentEncoder where @ is in the safe set.
>
> Sven
>
>> But, it's not the end of the road :-( Because in the next steps, Zinc encodes the character @ in the url.  How to disabled the automatic encoding and using special characters in the url ?
>>
>> Thanks for your help.
>>
>> Best regards
>> Olivier ;-)
>
>

> 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

> On 22 Oct 2013, at 15:49, "[hidden email]" <[hidden email]> 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_references#Character_entity_references_in_HTML
>> 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.

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

>
> On 22 Oct 2013, at 18:27, "[hidden email]" <[hidden email]> wrote:
>
>> Ok, point taken.
>>
>> Still, ZnClient is unusable for the intended purpose as is. No matter what encoding, % or not, Olivier cannot get the URL to work. Couldn't the ZnClient use something like the StampClient does: options? (where prefetch-count can be set for example - I also discovered the little inbox thing after some hair pulling sessions BTW).
>>
>>
>> Phil
>
> But Olivier's problem is that he is talking to a server that does not do proper percent decoding, IMHO. A server parsing a URL should resolve all percent encodings, after parsing using the significant delimiters (/ : ? #).
>
> http://foo.com/abc and http://foo.com/%61%62%63 are the same thing, just like http://foo.com/abc@1 and http://foo.com/abc%401 are - again as far as I understand it.
>
> That being said, I am going to study the specs again and might change what gets encoded or not depending on the URL element, instead of encoding aggressively in the better safe than sorry way.
>
> Olivier's suggestion about safer authorisation parsing does make sense and will get added as well - Thanks Olivier !
>
> Sven
>
> PS: BTW, ZnClient has such an option object already.
>
>

> Thanks for the improvement. Don't hesitate to contact me if I can help you
>
> Olivier ;-)
>
> Le 22 oct. 2013 à 18:49, Sven Van Caekenberghe a écrit :
>
>>
>> On 22 Oct 2013, at 18:27, "[hidden email]" <[hidden email]> wrote:
>>
>>> Ok, point taken.
>>>
>>> Still, ZnClient is unusable for the intended purpose as is. No matter what encoding, % or not, Olivier cannot get the URL to work. Couldn't the ZnClient use something like the StampClient does: options? (where prefetch-count can be set for example - I also discovered the little inbox thing after some hair pulling sessions BTW).
>>>
>>>
>>> Phil
>>
>> But Olivier's problem is that he is talking to a server that does not do proper percent decoding, IMHO. A server parsing a URL should resolve all percent encodings, after parsing using the significant delimiters (/ : ? #).
>>
>> http://foo.com/abc and http://foo.com/%61%62%63 are the same thing, just like http://foo.com/abc@1 and http://foo.com/abc%401 are - again as far as I understand it.
>>
>> That being said, I am going to study the specs again and might change what gets encoded or not depending on the URL element, instead of encoding aggressively in the better safe than sorry way.
>>
>> Olivier's suggestion about safer authorisation parsing does make sense and will get added as well - Thanks Olivier !
>>
>> Sven
>>
>> PS: BTW, ZnClient has such an option object already.
>>
>>
>
>