Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow non-percent-encoded spaces in path #739

Closed
wants to merge 1 commit into from

Conversation

WhyNotHugo
Copy link
Contributor

The space character is not a reserved character. While it MAY be used in percent-encoded form, this is not mandatory and it is acceptable to use raw spaces in URL paths.

Add Space (0x20) to the list of characters that don't need to be percent-encoded.

The space character is not a reserved character. While it MAY be used in
percent-encoded form, this is not mandatory and it is acceptable to use
raw spaces in URL paths.

Add Space (0x20) to the list of characters that don't need to be
percent-encoded.
@seanmonstar
Copy link
Member

I don't see any feasible way this could work, at least for HTTP/1. Parsers assume (because the spec defines this) that the request line is 3 tokens separate by spaces. A parser would be upset to see GET /hello world HTTP/1.1.

Note RFC 9112 3.2:

No whitespace is allowed in the request-target. Unfortunately, some user agents fail to properly encode or exclude whitespace found in hypertext references, resulting in those disallowed characters being sent as the request-target in a malformed request-line.

@WhyNotHugo
Copy link
Contributor Author

WhyNotHugo commented Dec 28, 2024 via email

@WhyNotHugo WhyNotHugo closed this Dec 28, 2024
@WhyNotHugo WhyNotHugo deleted the space-in-path branch December 28, 2024 18:09
@WhyNotHugo
Copy link
Contributor Author

I'm working on WebDAV, where URLs are sometimes specified in the request header, and sometimes inside an XML in the body. I've been using the same Uri type for both, but it seems that rules for percent-encoding the URIs inside the XML body are more relaxed.

Should I just use a separate type for those?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants