[hunchentoot-devel] hunchentoot cookie-values - url-encode them or not

Hans Hübner hans.huebner at gmail.com
Wed Feb 1 20:00:03 UTC 2012


Ralf, all,

I have made the change that Ralf pointed out because I had to read a
cookie value that was set by a Rails application and that was not
URL-encoded.  Thus, I'd question the claim that URL-encoding cookies
is a "de facto standard".  The HTTP standard does not mandate any
standard encoding for cookies, but only restricts their character set.

I am open to a check similar to one that Ralf proposed, although I
would have Hunchentoot generate an error when the application tries to
set a cookie that contains invalid characters.

-Hans

On Wed, Feb 1, 2012 at 8:23 PM, Ralf Stoye <stoye at stoye.com> wrote:
> As you can see on git, future hunchentoot versions will not url-encode/decode cookie-values anymore.
> Since this encoding is an de facto standard regarding php, java and perl,
> and it might break existing code, i would like to hear your opinion about that.
>
> At a minimum i want to suggest to introduce a sanity-check on #'cookie-values
> throwing an error if someone tries to set the value to a nonconforming value
> (similar to the check on valid cookie-names).
> The following code is an example predicate:
>
> (defun http-cookie-value-p (value)
>  "Tests whether VALUE is a string which is a valid cookie-value according to RFC 6265"
>  (and (stringp value)
>       (not (some (lambda (char)
>               (let ((cc (char-code char)))
>                 (or (< cc #x21)
>                      (= #x22 cc)
>                      (= #x2c cc)
>                      (= #x3b cc)
>                      (= #x5c cc)
>                      (> cc #x7e))))
>                  value))))
>
> the decision is a matter of performance versus simplicity:
> we could decide to always encode cookie values (eg. per base64 or url-encode, or both)
> or leave the decision and responsability to the application.
>
> Regards,
> Ralf Stoye
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




More information about the Tbnl-devel mailing list