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
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@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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi, let me correct my last post:
1. The standard is RFC 6265, but many people are used to url-encode. url-encoding is the common answer on lists & discussion-groups. 2. I didn't expressed clearly that i also want Hunchentoot to validate AND throwing an error when validation fails. 3. The given http-cookie-value-p is wrong. (doesn't honor the fact that it is allowed to wrap the Token in Doubleqoutes (#x22). 4. your example shows that the decision is not a matter of performance versus simplicity, it's about correctness.
So i vote for a correct implementation, validating the value and throwing an appropriate error.
Ralf
On Thu, Feb 2, 2012 at 3:13 PM, Ralf Stoye stoye@stoye.com wrote:
- The standard is RFC 6265, but many people are used to url-encode. url-encoding is the common answer on lists & discussion-groups.
- I didn't expressed clearly that i also want Hunchentoot to validate AND throwing an error when validation fails.
- The given http-cookie-value-p is wrong. (doesn't honor the fact that it is allowed to wrap the Token in Doubleqoutes (#x22).
- your example shows that the decision is not a matter of performance versus simplicity, it's about correctness.
So i vote for a correct implementation, validating the value and throwing an appropriate error.
I'll gladly merge a pull request with a patch that validates cookie values set by the application!
-Hans
-
Hans Hübner -
Ralf Stoye