<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">In writing some cookie-handling code I noticed that</div><div class=""><span class="Apple-tab-span" style="white-space:pre">      </span>1) the Racket net/cookie library is based on RFC 2109, obsoleted by two new cookie RFCs since then (the current being 6265)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">       </span>2) the net/cookie library’s imperative interface feels very un-Rackety</div><div class=""><br class=""></div><div class="">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):</div><div class=""><span class="Apple-tab-span" style="white-space:pre">  </span>[make-cookie
                        (->* (cookie-name? cookie-value?)</div><div class="">                          (#:expires    (or/c date? #f)</div><div class="">                           #:max-age    (or/c (and/c integer? positive?) #f)</div><div class="">                           #:domain     (or/c valid-domain? #f)</div><div class="">                           #:path       (or/c path/extension-value? #f)</div><div class="">                           #:secure?    boolean?</div><div class="">                           #:http-only? boolean?</div><div class="">                           #:extension  (or/c path/extension-value? #f))</div><div class="">                          cookie?)]</div><div class="">where cookie-name?, cookie-value?, and path/extension-value? are written as per RFC 6265.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">My question is, which approach would the Racket maintainers prefer:</div><div class=""><ol class="MailOutline"><li class="">add a new constructor, like the above, that does RFC6265 checking and leave all of net/cookie’s machinery otherwise untouched</li><li class="">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)</li><li class="">replace the old net/cookie interface altogether</li><li class="">add a differently-named library to net/ (and mark the old one as deprecated?)</li><li class="">add a library somewhere else (e.g., somewhere in web-server/)</li><li class="">just write a separate cookie package that can be made available via <a href="http://pkg.racket-lang.org" class="">pkg.racket-lang.org</a> (I noticed an undocumented attempt at this at <a href="https://github.com/Kalimehtar/client-cookies" class="">https://github.com/Kalimehtar/client-cookies</a>)</li><li class="">or something else?</li></ol><div class=""><br class=""></div><div class="">Regards,</div></div><div class="">jmj</div><div class=""><br class=""></div></body></html>