You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A regression was introduced between v0.10 and v0.12 for the URL parsing of an http.get() request. Basically, multi-byte characters are decoded as 'binary' instead of either
Yes. The test in the linked issue has the same result in io.js. A possible solution would be to simply parse the string with encodeURI() before turning it into a buffer using binary encoding.
@bnoordhuis Parsing the string this way follows more closely to the spec. Even though browsers may show the unicode characters in the URL bar, checking the network request shows it also decodes them before firing the request. io.js' http module would also barf on this request since we decode incoming headers using ISO-8859-1.
@vkurchatkin It does look like the same issue. IMO the options are to let the user know they need to encode their header strings before sending them, or we should consider doing that automatically before turning them into a buffer.
IMO the options are to let the user know they need to encode their header strings before sending them, or we should consider doing that automatically before turning them into a buffer.
Is there consensus at this time that one of these two options is superior to the other?
Activity
rvagg commentedon Jul 7, 2015
@trevnorris so to clarify, you're saying that io.js is impacted by this also (since we're not strictly an 0.12 fork that's not obvious)?
trevnorris commentedon Jul 7, 2015
Yes. The test in the linked issue has the same result in io.js. A possible solution would be to simply parse the string with
encodeURI()before turning it into a buffer using binary encoding.vkurchatkin commentedon Jul 7, 2015
This could be related: #1693
bnoordhuis commentedon Jul 7, 2015
It's probably the result of this change. Before f674b09, headers and the status line were parsed as UTF-8, now they're parsed as ISO-8859-1.
trevnorris commentedon Jul 7, 2015
@bnoordhuis Parsing the string this way follows more closely to the spec. Even though browsers may show the unicode characters in the URL bar, checking the network request shows it also decodes them before firing the request. io.js' http module would also barf on this request since we decode incoming headers using ISO-8859-1.
@vkurchatkin It does look like the same issue. IMO the options are to let the user know they need to encode their header strings before sending them, or we should consider doing that automatically before turning them into a buffer.
Fishrock123 commentedon Aug 31, 2015
Duplicate of #1693. See also: #2629
vkurchatkin commentedon Aug 31, 2015
I wouldn't say it's duplicate. There are two problems with UTF8: parsing and writing, and they seem unrelated.
http: Reject paths containing non-ASCII characters
Trott commentedon Apr 5, 2016
Is there consensus at this time that one of these two options is superior to the other?
trevnorris commentedon Apr 6, 2016
@Trott Nope. May just want to throw this into the CTC meeting for quick vote for fast resolution.
jasnell commentedon Jul 3, 2016
Should be addressed by the WHATWG URL impl here: #7448
ChALkeR commentedon Jul 3, 2016
@jasnell Does that change what
http.getsends?jasnell commentedon Jul 20, 2016
@ChALkeR ... actually no, it doesn't, you're right.
jasnell commentedon May 1, 2017
Does this need to remain open?
jasnell commentedon May 30, 2017
Closing given the lack of any further progress on this. It's not even clear if this is still an issue
Flimm commentedon May 30, 2017
I've created a very similar issue (with a failing test-case) here: #13296