Hyper and Rocket disagreeing on validity of URL

[Sebbito]

Rocket Version

0.5.0

Operating System

Fedora 39

Rust Toolchain Version

rustc 1.72.0-nightly (6162f6f12 2023-07-01)

What happened?

When firing a request to a non-existent URL with the string literal "http://localhost:8000/artists/{id}" (or any URL containing curly braces) rocket returns a 404 as expected with the following warning:

Warning: Hyper/Rocket URI validity discord: "/artists/{id}"
   >> Hyper believes the URI is valid while Rocket disagrees.
   >> This is likely a Hyper bug with potential security implications.
   >> Please report this warning to Rocket's GitHub issue tracker.
GET /artists/{id}:
   >> No matching routes for GET /artists/{id}.
   >> No 404 catcher registered. Using Rocket default.
   >> Response succeeded.

I am not sure whether this does actually imply any security problems or not, I'm just here to report my find as instructed.

Test Case

/

Log Output

/

Additional Context

No response

System Checks

• My bug report relates to functionality.
• I have tested against the latest Rocket release or a recent git commit.
• I have tested against the latest stable rustc toolchain.
• I was unable to find this issue previously reported.

[SergioBenitez]

It's definitely not a valid URL. Those curly braces should be percent-encoded, and hyper should be rejecting. This doesn't appear to be an exception, like curly braces in queries, where browsers allow them even though they don't conform to the spec: Chrome, Firefox, and Safari all percent-encode curly braces in paths.

This one is a bit concerning because { and } are often used for templating, and so allowing this URI to go through could potentially result in something downstream templating a URI when it shouldn't. That if, if it believes a valid URI won't contain { or } (which should be the case), then it may believe it is "safe" to assume a URI containing such characters should be templatized. This could allow an attacker to extract information from certain applications by carefully crafting URIs.

I'll raise an issue with hyper, though other such issue have not had much luck.

[SergioBenitez]

Reported at hyperium/hyper#3594. Thank you for bringing this up.

[Sebbito]

No problem!

It's odd that they would allow this.

send requests with JSON directly embedded in the URI path. Yes, those things happen for real.

That seems like a terrible hack and it should not be supported by anyone.