-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
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. |
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. |
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. |
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. |
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.
CC - Data [ Version: alpha 97 Type: Bug Platform: All Category: Mezzanine Reproduce: Always Fixed-in:none ]
The text was updated successfully, but these errors were encountered: