Skip to content

URL: dedotdotification not done on %2e #16869

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

Closed
bagder opened this issue Mar 29, 2025 · 0 comments
Closed

URL: dedotdotification not done on %2e #16869

bagder opened this issue Mar 29, 2025 · 0 comments
Assignees
Labels

Comments

@bagder
Copy link
Member

bagder commented Mar 29, 2025

I did this

Section 5.2.4 of RFC 3986 describes how to "Remove Dot Segments". What I call dedotdotification. A path like /hello/../foobar should become /foobar in the request.

In a URL, said dots (periods) can be encoded as %2e, meaning that /hello/%2e%2e/foobar should also end up /foobar in the request. In current curl, this does not happen when one or two of the dots are percent encoded. The same goes for removing /%2e/ sequences, when the period is encoded.

I expected the following

Correct dedotdotification.

curl/libcurl version

current curl master

operating system

any

@bagder bagder added the URL label Mar 29, 2025
@bagder bagder self-assigned this Mar 29, 2025
bagder added a commit that referenced this issue Mar 29, 2025
Treat %2e and %2E to be "dot equivalents" in the function and remove
such sequences as well, according to RFC 3986 section 5.2.4. That is
also what the browsers do.

This DOES NOT consider %2f sequences in the path to be actual slashes,
so there is not removal of dots for those.

This function does not decode nor encode any percent sequences.

Extends test 1395 and 1560 to verify.

Fixes #16869
bagder added a commit that referenced this issue Mar 29, 2025
Treat %2e and %2E to be "dot equivalents" in the function and remove
such sequences as well, according to RFC 3986 section 5.2.4. That is
also what the browsers do.

This DOES NOT consider %2f sequences in the path to be actual slashes,
so there is not removal of dots for those.

This function does not decode nor encode any percent sequences.

Extends test 1395 and 1560 to verify.

Fixes #16869
bagder added a commit that referenced this issue Mar 29, 2025
Treat %2e and %2E to be "dot equivalents" in the function and remove
such sequences as well, according to RFC 3986 section 5.2.4. That is
also what the browsers do.

This DOES NOT consider %2f sequences in the path to be actual slashes,
so there is not removal of dots for those.

This function does not decode nor encode any percent sequences.

Extends test 1395 and 1560 to verify.

Fixes #16869
Closes #16870
bagder added a commit that referenced this issue Mar 30, 2025
Treat %2e and %2E to be "dot equivalents" in the function and remove
such sequences as well, according to RFC 3986 section 5.2.4. That is
also what the browsers do.

This DOES NOT consider %2f sequences in the path to be actual slashes,
so there is not removal of dots for those.

This function does not decode nor encode any percent sequences.

Also switched the code to use dynbuf.

Extends test 1395 and 1560 to verify.

Fixes #16869
Closes #16870
@bagder bagder closed this as completed in c31dd66 Mar 31, 2025
pps83 pushed a commit to pps83/curl that referenced this issue Apr 26, 2025
Treat %2e and %2E to be "dot equivalents" in the function and remove
such sequences as well, according to RFC 3986 section 5.2.4. That is
also what the browsers do.

This DOES NOT consider %2f sequences in the path to be actual slashes,
so there is no removal of dots for those.

This function does not decode nor encode any percent sequences.

Also switched the code to use dynbuf.

Extends test 1395 and 1560 to verify.

Assisted-by: Demi Marie Obenour

Fixes curl#16869
Closes curl#16870
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

1 participant