<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 7, 2015 at 2:18 PM, Jordan Johnson <span dir="ltr"><<a href="mailto:jmj@fellowhuman.com" target="_blank">jmj@fellowhuman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi all,<div><br></div><div>In writing some cookie-handling code I noticed that</div><div><span style="white-space:pre-wrap"> </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><span style="white-space:pre-wrap"> </span>2) the net/cookie library’s imperative interface feels very un-Rackety</div></div></blockquote><div><br></div><div>I very much agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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><span style="white-space:pre-wrap"> </span>[make-cookie
(->* (cookie-name? cookie-value?)</div><div> (#:expires (or/c date? #f)</div><div> #:max-age (or/c (and/c integer? positive?) #f)</div><div> #:domain (or/c valid-domain? #f)</div><div> #:path (or/c path/extension-value? #f)</div><div> #:secure? boolean?</div><div> #:http-only? boolean?</div><div> #:extension (or/c path/extension-value? #f))</div><div> cookie?)]</div><div>where cookie-name?, cookie-value?, and path/extension-value? are written as per RFC 6265.</div></div></blockquote><div><br></div><div>Yes, I think that would be the best.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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><br></div><div>My question is, which approach would the Racket maintainers prefer:</div><div><ol><li>add a new constructor, like the above, that does RFC6265 checking and leave all of net/cookie’s machinery otherwise untouched</li><li>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>replace the old net/cookie interface altogether</li><li>add a differently-named library to net/ (and mark the old one as deprecated?)</li><li>add a library somewhere else (e.g., somewhere in web-server/)</li><li>just write a separate cookie package that can be made available via <a href="http://pkg.racket-lang.org" target="_blank">pkg.racket-lang.org</a> (I noticed an undocumented attempt at this at <a href="https://github.com/Kalimehtar/client-cookies" target="_blank">https://github.com/Kalimehtar/client-cookies</a>)</li><li>or something else?</li></ol></div></div></blockquote></div>I prefer a combination of 3, 4 and 6. You should stake out a new name like net/cookies or net/rfc6265 or something. Make a package that provides that and send a pull request that changes the net/cookie docs to mark it as deprecated.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks so much!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jay<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jay McCarthy<br><a href="http://jeapostrophe.github.io" target="_blank">http://jeapostrophe.github.io</a><br><br> "Wherefore, be not weary in well-doing,<br> for ye are laying the foundation of a great work.<br>And out of small things proceedeth that which is great."<br> - D&C 64:33</div>
</div></div>