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
If I'm reading RFC3986, correctly (and I may not be), it says that any data characters falling outside the allowed set for a component, must be percent encoded.
So, I understand why passing this string to encode would not encode as expected:
encode correctly sees the ? as a delimiter and not as data. I then figured that if I built the URI by specifying each part, that encode would call encode_component on each piece separately. But the following produces the same results as above:
uri = Addressable::URI.parse("http://example.com")
uri.path << "/to_be_or_not_to_be?.txt"
Addressable::URI.encode(uri)
Looking at the code, it's because encode converts the argument passed to it to a string, regardless of whether or not it's a URI, calls parse on the resulting string to create a new URI and then encodes each component separately. It's that intermediate to string and parse that, while technically correct, is not what we intended (it'll treat that ? as the beginning of the query string).
I think this is a bug because looking at line 575 (in v2.3.6), there is a check to see if it's a URI. But it'll never be a URI because if you look up at the preceding begin/rescue, it's being converted to a string if it's anything but a string.
The text was updated successfully, but these errors were encountered:
If I'm reading RFC3986, correctly (and I may not be), it says that any data characters falling outside the allowed set for a component, must be percent encoded.
So, I understand why passing this string to encode would not encode as expected:
encode
correctly sees the?
as a delimiter and not as data. I then figured that if I built the URI by specifying each part, thatencode
would callencode_component
on each piece separately. But the following produces the same results as above:Looking at the code, it's because
encode
converts the argument passed to it to a string, regardless of whether or not it's a URI, calls parse on the resulting string to create a new URI and then encodes each component separately. It's that intermediate to string and parse that, while technically correct, is not what we intended (it'll treat that?
as the beginning of the query string).I think this is a bug because looking at line 575 (in v2.3.6), there is a check to see if it's a URI. But it'll never be a URI because if you look up at the preceding begin/rescue, it's being converted to a string if it's anything but a string.
The text was updated successfully, but these errors were encountered: