Issue #19916 has been updated by jeremyevans0 (Jeremy Evans). I agree this is a bug. There's a few ways to fix it: 1. Convert the relative path to absolute path when host/port is set. 2. Raise if path is relative when setting host/port. 3. Change URI#to_s to add a slash for a relative path if there is a host/port. 4. Make URI#to_s raise if there is a host/port and a relative path Of these options, I think option 3 is best. The main problem with option 1 is that information is that uri.path changes. I think if the uri was set with a relative path, then uri.path should be relative. Raising an error is possible by calling `check_path` in some additional methods, but it results in weird errors (invalid path even though you aren't trying to set a new path), and won't fix the issue for ftp, where relative paths are allowed. So I don't think option 2 is good either. Option 4 would work, but most code does not expect `to_s` to raise. I submitted a pull request upstream for option 3: https://github.com/ruby/uri/pull/90 ---------------------------------------- Bug #19916: URI#to_s can serialize to a value that doesn't deserialize to the original https://bugs.ruby-lang.org/issues/19916#change-105063 * Author: yawboakye (yaw boakye) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It appears that when we're serializing a URI to string, we don't check/confirm that it is represented in a form that can be deserialized back into the original. I think it's fair to expect that serialize+deserialize produces an object that is the same as the original, only differing perhaps in terms of the unique object identifier. This isn't the case with URI when they are custom built, which might happen a lot, for example in a Rails app that accepts URL inputs from users. Let me attempt a reproduction, using the generic URI `example.com`. ```ruby example_url = "example.com" example_uri = URI(example_url) ``` Given that no scheme is explicitly set in the URI, it is correctly parsed as generic, with the given `example.com` interpreted as the path. The object returned to is mutable. Since we didn't automatically detect a scheme, let's fix that as well as the hostname. ``` ruby example_uri.scheme = "https" example_uri.hostname = example_uri.path # I've intentionally left path value unchanged, since it helps demonstrate the potential bug. ``` Given that we have a scheme, an authority, and a path, and given that we format URI according to [RFC 3986], one may expect that serializing the URI to string will follow the guidelines of section 3 of the RFC: [Syntax Components], which requires a slash separator between the authority (in our case hostname) and the path. It appears that `URI#to_s` may not do that if path didn't already have a slash prefix. Which would be fine if we were keeping an invariant that ensured that we never produced bad serialized URI. To return to our `example_uri`, serialization produces: ```ruby serialized_uri = example_uri.to_s puts serialized_uri # https://example.comexample.com ``` This is obviously bad. One would have expected `https://example.com/example.com` instead. That is, the slash will be automatically and correctly inserted, just as the double slashes were automatically inserted between the scheme and and the authority. `serialized_uri` cannot be deserialized into `example_uri`, in fact. Below is an attempt at deserialization and a comparison of the new value to the original: ```ruby deserialized_example_uri = URI(serialized_uri) example_uri.scheme == deserialized_example_uri.scheme # true example_uri.hostname == deserialized_example_uri.hostname # false (for, example.com =/= example.comexample.com) example_uri.path == deserialized_example_uri.path # false (for, example.com =/= "") ``` I believe that the ability to serialize and deserialize an object without losing fidelity is a great thing. I believe even more strongly that we should preserve/maintain an invariant that allows us to always serialize a URI to a format that meets the RFC's specification. Therefore I consider this a bug, and I'd be willing to work on a fix, as my first contribution to Ruby, if enough people consider it a bug too. Regards! [RFC 3986]: https://www.rfc-editor.org/rfc/rfc3986 [Syntax Components]: https://www.rfc-editor.org/rfc/rfc3986#section-3 ---Files-------------------------------- Screenshot 2023-09-29 at 12.19.26.png (180 KB) -- https://bugs.ruby-lang.org/

Issue #19916 has been updated by knu (Akinori MUSHA). It is not appropriate to parse a path string with URI() without specifying any scheme or base URI. If you know the piece of text is a path in the HTTP protocol, you should say something like this: ```ruby url = URI.join("http:", "example.com") p url #=> #<URI::HTTP http:/example.com> url.hostname = "foo" p url #=> #<URI::HTTP http://foo/example.com> p uri.to_s #=> "http://foo/example.com" ``` ---------------------------------------- Bug #19916: URI#to_s can serialize to a value that doesn't deserialize to the original https://bugs.ruby-lang.org/issues/19916#change-105240 * Author: yawboakye (yaw boakye) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It appears that when we're serializing a URI to string, we don't check/confirm that it is represented in a form that can be deserialized back into the original. I think it's fair to expect that serialize+deserialize produces an object that is the same as the original, only differing perhaps in terms of the unique object identifier. This isn't the case with URI when they are custom built, which might happen a lot, for example in a Rails app that accepts URL inputs from users. Let me attempt a reproduction, using the generic URI `example.com`. ```ruby example_url = "example.com" example_uri = URI(example_url) ``` Given that no scheme is explicitly set in the URI, it is correctly parsed as generic, with the given `example.com` interpreted as the path. The object returned to is mutable. Since we didn't automatically detect a scheme, let's fix that as well as the hostname. ``` ruby example_uri.scheme = "https" example_uri.hostname = example_uri.path # I've intentionally left path value unchanged, since it helps demonstrate the potential bug. ``` Given that we have a scheme, an authority, and a path, and given that we format URI according to [RFC 3986], one may expect that serializing the URI to string will follow the guidelines of section 3 of the RFC: [Syntax Components], which requires a slash separator between the authority (in our case hostname) and the path. It appears that `URI#to_s` may not do that if path didn't already have a slash prefix. Which would be fine if we were keeping an invariant that ensured that we never produced bad serialized URI. To return to our `example_uri`, serialization produces: ```ruby serialized_uri = example_uri.to_s puts serialized_uri # https://example.comexample.com ``` This is obviously bad. One would have expected `https://example.com/example.com` instead. That is, the slash will be automatically and correctly inserted, just as the double slashes were automatically inserted between the scheme and and the authority. `serialized_uri` cannot be deserialized into `example_uri`, in fact. Below is an attempt at deserialization and a comparison of the new value to the original: ```ruby deserialized_example_uri = URI(serialized_uri) example_uri.scheme == deserialized_example_uri.scheme # true example_uri.hostname == deserialized_example_uri.hostname # false (for, example.com =/= example.comexample.com) example_uri.path == deserialized_example_uri.path # false (for, example.com =/= "") ``` I believe that the ability to serialize and deserialize an object without losing fidelity is a great thing. I believe even more strongly that we should preserve/maintain an invariant that allows us to always serialize a URI to a format that meets the RFC's specification. Therefore I consider this a bug, and I'd be willing to work on a fix, as my first contribution to Ruby, if enough people consider it a bug too. Regards! [RFC 3986]: https://www.rfc-editor.org/rfc/rfc3986 [Syntax Components]: https://www.rfc-editor.org/rfc/rfc3986#section-3 ---Files-------------------------------- Screenshot 2023-09-29 at 12.19.26.png (180 KB) -- https://bugs.ruby-lang.org/