Hi all,
In writing some cookie-handling code I noticed that
1) the Racket net/cookie library is based on RFC 2109, obsoleted by two
new cookie RFCs since then (the current being 6265)
2) the net/cookie library’s imperative interface feels very un-Rackety
I initially just wanted to be able to use the HttpOnly flag, and later got to
thinking it’d be more Rackety to have a cookie constructor based on keyword
args, like (using provide/contract syntax):
[make-cookie (->* (cookie-name? cookie-value?)
(#:expires (or/c date? #f)
#:max-age (or/c (and/c integer? positive?) #f)
#:domain (or/c valid-domain? #f)
#:path (or/c path/extension-value? #f)
#:secure? boolean?
#:http-only? boolean?
#:extension (or/c path/extension-value? #f))
cookie?)]
where cookie-name?, cookie-value?, and path/extension-value? are written as per
RFC 6265.
So I’ve done some work and would like to eventually volunteer an updated cookie
lib that complies with the newer RFC. Thing is, it’s going to be
backward-incompatible in some small ways, since RFC 6265 disallows some things
(like double-quotes as non-start/end chars of a cookie value) that net/cookie
permits.
My question is, which approach would the Racket maintainers prefer:
add a new constructor, like the above, that does RFC6265 checking and leave all
of net/cookie’s machinery otherwise untouched
do the above and also add RFC 6265 checks to the relevant cookie:... functions
in the library (which involves rewriting the tests and may break some old apps
that use it)
replace the old net/cookie interface altogether
add a differently-named library to net/ (and mark the old one as deprecated?)
add a library somewhere else (e.g., somewhere in web-server/)
just write a separate cookie package that can be made available via
pkg.racket-lang.org (I noticed an undocumented attempt at this at
https://github.com/Kalimehtar/client-cookies)
or something else?
Regards,
jmj
____________________
Racket Users list:
http://lists.racket-lang.org/users
