[hunchentoot-devel] Probably a bug in url-encode/url-decode
Hi, I encountered the following problem: CL-USER> (hunchentoot:url-decode "+") " " CL-USER> (hunchentoot:url-encode "+") "%2B" But in JavaScript:
encodeURI("+") "+" decodeURI("+") "+"
This is a bug? Andrey
On Thu, Mar 18, 2010 at 4:45 PM, Andrey Moskvitin <archimag@gmail.com> wrote:
Hi, I encountered the following problem: CL-USER> (hunchentoot:url-decode "+") " " CL-USER> (hunchentoot:url-encode "+") "%2B" But in JavaScript:
encodeURI("+") "+" decodeURI("+") "+" This is a bug? Andrey
No, it just depends on which RFC you follow that describes URL escaping. For example, PHP has two different url-escaping functions to handle the two RFCs - urlencode (like hunchentoot's url-encode), and rawurlencode (like javascript's encodeURI). That said, the behavior of javascript's encode functions are generally more common. ~TJ
No, it just depends on which RFC you follow that describes URL escaping.
Which? In JavaScript used encodeURI for URL and encodeURIComponent for single components. hunchentoot:url-decode does not match any of these functions. Browser does not replace # \+ to "%2B" in header when sending request to the server. A substitute # \ + at # \ Space, as does hunchentoot:url-decode, need for forms, but not for the url. I have wrong understanding? Andrey
Try Javascript escape/unescape. There's still an issue with + but that's the only one. I tend to just use a regex replace in the Javascript to replace + with some uncommon string before sending it to the server and then doing the reverse replacement when I get the string back. For all other symbols I tried, escape/unescape matched url-encode/url-decode. Jordan On 03/19/2010 08:36 AM, Andrey Moskvitin wrote:
No, it just depends on which RFC you follow that describes URL escaping.
Which? In JavaScript used encodeURI for URL and encodeURIComponent for single components. hunchentoot:url-decode does not match any of these functions. Browser does not replace # \+ to "%2B" in header when sending request to the server. A substitute # \ + at # \ Space, as does hunchentoot:url-decode, need for forms, but not for the url.
I have wrong understanding?
Andrey
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
And for anyone who is wondering what is meant by "RFC" in this context: Tab Atkins Jr. wrote:
No, it just depends on which RFC you follow that describes URL escaping.
See section 2 of this document: http://www.ietf.org/rfc/rfc2396.txt - Dan
For example, PHP has two different url-escaping functions to handle the two RFCs - urlencode (like hunchentoot's url-encode), and rawurlencode (like javascript's encodeURI).
That said, the behavior of javascript's encode functions are generally more common.
~TJ
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
See section 2 of this document:
<http://www.ietf.org/rfc/rfc2396.txt>Hmm, I can't find a explanation in this RFC why the function huchentoot:url-decode substitute # \+ at # \Space :( Andrey
See section 2 of this document:
Hmm, I can't find a explanation in this RFC why the function huchentoot:url-decode substitute # \+ at # \Space :( Yes, apparently if you put a "+" in the string that is
Sorry, actually the latest spec is http://tools.ietf.org/html/rfc3986 See also http://en.wikipedia.org/wiki/Percent-encoding Andrey Moskvitin wrote: the argument to huchentoot:url-decode, it turns into a space. However, I don't think it is legal/valid to have a "+" character in an encoded URI. Do you know of a string (call it s) such that (equalp (hunchentoot:url-decode (hunchentoot:url-encode s)) s) is false?
Andrey
------------------------------------------------------------------------
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
However, I don't think it is legal/valid to have a "+" character in an encoded URI.
However, when you type in your browser http://localhost:8080/foo+/bar+/, then (hunchentoot: request-uri *) returns "/foo+ /bar+/" (not"/foo%2B/bar%2B/" ). I specifically checked that mod_autoindex (Apache) in such cases is also not encode +. Andrey
participants (4)
-
Andrey Moskvitin -
Daniel Weinreb -
Jordan Powell -
Tab Atkins Jr.