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