wxURI and URL encoding

[eranon]

Hello,

Is not wxURI supposed to encode the URL?

When I provide an URL as "http://user:pass@server/" with the user containing a "@", it fails to parse the elements (eg. here wxURI::GetPassword doesn't return the pass because wxURI considers the first "@" as being the separation between user:pass pair and the server).

So, I tried something like this, expecting to obtain an explicitely encoded URL after wxURI::BuildURI, but it doesn't seem to be the case... Or I missed something somewhere °O°

Code: Select all

    wxString strUrl("http://user@account:pass@server/");
    wxURI uri(strUrl);
    wxString strEncodedUrl = uri.BuildURI();                    // "@" did not become "%40" as I expected

--
EDIT: What I expected seems to be confirmed here: viewtopic.php?t=9233, so at this step, I don't know...

[eranon]

Well, if I encode the "@" inside username as "%40" before to go with wxURI, it works (wxURI well parses the URL). So, it sounds that reserved characters in wrong places have to be encoded upstream... In my enthousiasm, I thought wxURI was able to handle this kind of case since it's not rare to see "@" in username and/or password these days. So, solved for tonight

[ONEEYEMAN]

Hi,
Are you using wxWebView? Might be a good case for a trac ticket if you can reproduce it in the sample/test suite.

Thank you.

[eranon]

Hi,

I don't use wxWebView in the concerned app, but I think this wxURI behavior will be the same whatever the app. In fact, after I saw this, I asked myself if it was a bug or a way to strictly follow (stick to) the concerned RFC. The chars "@" and ":" are here a reserved characters used to separate the URI elements and are not supposed to be encoded. So, the reasoning could be to say that the developer is responsible for the preparation of these so-called reserved characters when they do not appear in the positions reserved for them.

Of course, I think I can add these four or five lines of code in a short test app and attach it to an issue report, but... What do you think on your part? Bug or feature? Issue or compliance to the standard?

[coderrc]

in general, I would expect URL "parts" (eg username, password, etc) to come from somewhere external to the final url consumer either as user input or from some generator function. It should really be up to those inputs to properly format their output. blah blah unit testing blah separation of concerns blah blah blah.

Imagine writing the interpreter for a slightly modified version of your example.

Code: Select all

("http://user@account:pass:word@server/");

It might not be hard, but I cant be bothered to think about how I would write an interpreter that accurately reflected the intent.

but if the username and password sort themselves out, the task becomes trivial.

[eranon]

but if the username and password sort themselves out, the task becomes trivial.

Afterward (after my initiale surprise about this wxURI's behavior), I have the same opinion, coderrc. Because of this, I hesitate to open a ticket... Unless someone comes with a contrary informed opinion and/or a piece of software which would act in a different way and would make "jurisprudence".