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.txtHmm, I can't find a explanation in this RFC why the function huchentoot:url-decode substitute # + at # \Space :(
Andrey
Sorry, actually the latest spec is
http://tools.ietf.org/html/rfc3986
See also http://en.wikipedia.org/wiki/Percent-encoding
Andrey Moskvitin wrote:
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 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