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

DECODE-URL and url! syntax don't obey the url encoding rules #1644

Open
rebolbot opened this issue Sep 2, 2010 · 6 comments
Open

DECODE-URL and url! syntax don't obey the url encoding rules #1644

rebolbot opened this issue Sep 2, 2010 · 6 comments

Comments

@rebolbot
Copy link
Collaborator

rebolbot commented Sep 2, 2010

Submitted by: BrianH

Hex-encoded characters in URLs are supposed to stay encoded until the URL is broken into its component parts. This does not happen correctly with REBOL URLs: They are decoded too early. This causes a problem when one or more of the component parts have characters in them that would be mistaken for structural characters. This happens pretty often nowadays with many sites that use a full email address as a user name, or that allow passwords with less restricted character sets.

This can probably be solved by fixing DECODE-URL. Note: This problem also exists in R2, and could use a similar solution.

>> http://user%40rebol.com:blah@www.rebol.com/
== http://user@rebol.com:blah@www.rebol.com/
; should be http://user%40rebol.com:blah@www.rebol.com/
>> decode-url http://user%40rebol.com:blah@www.rebol.com/
== [scheme: 'http user: "user" host: "rebol.com" path: ":blah@www.rebol.com/"]
; should be [scheme: 'http pass: "blah" user: "user@rebol.com" host: "www.rebol.com" path: "/"]

CC - Data [ Version: alpha 97 Type: Bug Platform: All Category: Mezzanine Reproduce: Always Fixed-in:none ]

@rebolbot
Copy link
Collaborator Author

rebolbot commented Sep 2, 2010

Submitted by: BrianH

Gabriele wrote a correct parser here: http://www.rebol.it/power-mezz/parsers/uri-parser.html

Perhaps we can adapt that to R3 style, or at least analyze the code to get the correct rules to follow. We can't use it directly because it decodes the URLs too far, decoding the path and fragment identifier when we don't want that in this case. But it shouldn't be too hard to adapt, as long as it doesn't use too much of the rest of the Power Mezz stuff.

@rebolbot
Copy link
Collaborator Author

rebolbot commented Sep 7, 2010

Submitted by: meijeru

The following tickets also apply: #482, #1327, #1333.

@rebolbot
Copy link
Collaborator Author

Submitted by: Carl

This does not seem like hex decoding problem, but more like a field decoding problem in DECODE-URL. For example, in the example, I could have used the @ directly, without the %40.

@rebolbot
Copy link
Collaborator Author

Submitted by: BrianH

But what if the hex was %2F or some other character? All hex characters need to be allowed when specified in hex form.

@rebolbot
Copy link
Collaborator Author

rebolbot commented Apr 5, 2013

Submitted by: Ladislav

"This can probably be solved by fixing DECODE-URL." - this provably can't be solved by "fixing" DECODE-URL in any way.

@rebolbot
Copy link
Collaborator Author

rebolbot commented Apr 5, 2013

Submitted by: BrianH

Agreed, the internal treatment of url! values by LOAD and the other url! manipulation functions would need to be changed first, because url! values are getting corrupted long before DECODE-URL ever sees them. Once those other functions are fixed, and possibly a new internal model for the url! type is chosen (see #2014), then DECODE-URL can be fixed to work on the new url! data model.

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

No branches or pull requests

1 participant