#58 UserAgent incorrectly urlencoded

[Martimus8]

This is an excerpt from the help forum for this project
...
Q: Is aria2 passing the urlencoded string or is it passing my preferred urldecoded string in the http headers? (for the UserAgent)

A: In line 86 and line 137 of the HttpRequest.cc it currently has in 0.11.3:

"User-Agent: "+Util::urlencode(userAgent)+"\r\n"+

but it SHOULD HAVE one of two options:

option 1
"User-Agent: "+Util::urldecode(userAgent)+"\r\n"+

option 2
"User-Agent: "+userAgent+"\r\n"+

I'm currently using option 1 (in my source code) and have verified that it matches the UserAgent that is passed in Mozilla Firefox 2.0.0.7 for a download via their normal download method.

[tujikawa]

Logged In: YES
user_id=1450148
Originator: NO

Encoding user agent is wrong. This is a bug.

I think option2 is simpler way because userAgent is not URL-encoded string in aria2.

Did you test option2?

[Martimus8]

Logged In: YES
user_id=1897897
Originator: YES

Yes Option 2 compiles and works correctly.

Option 1 is more "safe", if a user accidentally passed a urlencoded string, it will decode it...however
Option 2 is more like just passing it through, making it transparent.

I put both options in because I don't know what the overall goal of aria2 is... safer or transparency.

[tujikawa]

Logged In: YES
user_id=1450148
Originator: NO

Decoding user specifed string is sometimes dangerous.
Imagine that a user specifies --user-agent='aria2%0D%0Aheader1: abc'.
If option1 is used, then the request header is:

GET / HTTP/1.1
User-Agent: aria2
header1: abc
Accept: /

See header1 is injected. This is not what we expect.

URL-encoded string doesn't cause this kind of problem.

[Martimus8]

Logged In: YES
user_id=1897897
Originator: YES

One can debate as well with the following imaginary situation too where it's using Option 2:
-U 'aria2\n\012header1: abc'

My posting point is that the User Agent is currently urlencoded, which is absolutely incorrect... whatever the "author(s)" of this software decides to do with those lines of codes, is up to them on choosing Option 1, Option 2 or perhaps something not mentioned.

And I'm not quite clear on the context of your statement of "URL-encoded string doesn't cause this kind of problem."... but I can say the User Agent should NEVER BE URL-ENCODED when sent to the server. Transparency seems to be what I'm gathering from the reponses as being the potential route to go though. (e.g. let someone else make the 'feature' in their code, and just pass it through to the server.) I'll eagerly await 0.11.4 with the correction that is decided upon for this "bug".

[tujikawa]

Logged In: YES
user_id=1450148
Originator: NO

My decision is to use option2. aria2 doesn't care the user agent string in the command-line option is URL-encoded or not.

In both option1 and option2, user can inject arbitrary header using -U option. I have to fix it, but this is an another issue.
The simplest way is to replace unsafe characters(CR, LF, etc) with ' '.

[tujikawa]

Logged In: YES
user_id=1450148
Originator: NO

Closing, because 0.11.4 doesn't encode user-agent.

[Martimus8]

Logged In: YES
user_id=1897897
Originator: YES

Reopening because line 137 in version 0.11.4 is STILL urlencoding in file HttpRequest.cc in src folder.

Please note this is mentioned in my original bug report.

[tujikawa]

Logged In: YES
user_id=1450148
Originator: NO

Thank you for pointing out the mistake. I've fixed the bug and committed to svn(r43).

[tujikawa]

Logged In: YES
user_id=1450148
Originator: NO

Closing, 0.11.5 release fixes this problem.