<div dir="ltr">As long as people are discussing http client libraries, I've been wondering what the status of net/cookie is. It seems that it's geared towards server-side cookie management (and I don't see an obvious way to generate Cookie: headers from net/cookie structs since none of the accessors are exported). Is there an existing or planned cannonical solution to managing cookies on the client side?<br> <br>Thanks,<br>Evan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 11:21 AM, Erik Pearson <span dir="ltr"><<a href="mailto:erik@adaptations.com" target="_blank">erik@adaptations.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just finishing up a two day wrestling match with net/url, couchdb, and assorted other incomplete libraries ... I have some fresh insight.<div> <br><div>First, the new http client library will be very welcome!</div> <div><br></div><div>A quick review of the existing code relieves me of most of my worries about net/url, which is a bit of a beautiful mess. In particular, I think that some of the code that analyzes the header is too brittle. In net/url a header is expected to be nearly perfectly formed. For instance, the "chunked" condition is tested for by a match against the literal header string "Transfer-Encoding: chunked". Just a difference in case, or an extra space somewhere will lead to a false negative. In the new code, this is done by a much more forgiving regexp comparison. However, I'm not sure this goes far enough. More on that in a sec.</div> </div><div><br></div><div>I would like to make some recommendations:</div><div>- keep text as bytstrings -- it looks like this is the way the new library works (but not net/url.)</div><div>- the status line should be parsed and the status code converted to an integer.</div> <div>- The header should be parsed into the simplest usable form. I would suggest that an alist, with the key being a lower cased symbol and the value being the original bytestring. </div><div>- When forming a header for a request, the same format should be used. I realize that if one wants proper-cased field names, the library will need to perform this formatting.</div> <div>- All information should be made available back to the api user.</div><div>- Standard header field values should be optionally parsed</div><div><br></div><div>These changes would make the library much more useful. It would be consistent with http library design across languages. It would also promote more uniformity across Racket libraries which use them. I've found that when diving into a library (currently I'm dealing with couchdb) that has to reinvent the http wheel -- it may be reinvented with a slight twist. If one is using multiple libraries together, each with a different idea of what a header or https status line is, well, things get really unnecessarily complicated.</div> <div><br></div><div>I think the core library could benefit from this as well. For instance, when looking for fields in the header, it would be more reliable to find the field in an alist, than to use an regex to extract values out of the bytestring. This is a very common operation when dealing with http, and I think it should be as simple and reliable as practical.</div> <div><br></div><div>Finally I would recommend that there be a facility for decoding and encoding standard header fields. The application of the parsing would be optional, but I think it is important to have an implementation in the core library. The header field names and formats are well specified, and there are not all that many of them. They could be supplied as a hash or aref, with the field name lower-cased symbol (as in the parsed header) as key and two functions, one to decode from a bytstring, and one to encode into a bytestring. The simplest, most racketiest data structure would be best. A library user could grab this translation database and extend or modify it at will, but they would have a great head start.</div> <div><br></div><div>Anyway, this is far from exhaustive, but these are some of the issues I've grappled with in recent hours and are right on the top of my head.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"> <div class="im"> On Tue, Sep 17, 2013 at 6:51 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>></span> wrote:<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I think it's an obvious request, but a character flaw of mine is not<br> doing things unless they can be done really good. In this case, I see<br> a hash table as a "parse" of the headers. It's not obvious to me how<br> to parse them. For example...<br> <br> - The same header can appear many times, so (Key -> Value) is<br> incorrect, unless you overwrite one. It would be better to have (Key<br> -> (Listof Value)) but that feels really ugly since most of the time<br> there will just be one<br> - The spec doesn't mandate case sensitivity on headers, so I would<br> need to canonicalize "ACCept-ENCodiNG" to something else. Maybe<br> 'Accept-Encoding?<br> - The value of many headers is not really a string. For instance,<br> Content-Length is a number, Cache-Control is an association list,<br> Content-Disposition is complicated, etc. I feel like it is<br> disingenuous to only partial parse.<br> - Dealing with all this may be wasted effort for most requests that<br> just care about the body<br> <br> For these reasons, I think http-client should just return the list of<br> bytes. I think it would be nice to have another function that parses<br> that so clients could optionally call it if it is important. That can<br> be part of http-client.<br> <br> Jay<br> <br> <br> <br> On Tue, Sep 17, 2013 at 3:41 AM, adam moore <<a href="mailto:nerdfunk@gmail.com" target="_blank">nerdfunk@gmail.com</a>> wrote:<br> > Hi Jay,<br> ><br> > Just looking over the new http client code - looking very nice, and<br> > much better than my current slapped together parsing of<br> > get-impure-port.<br> ><br> > I was wondering if it might be better to pass back the headers as<br> > something easier to look up against, for example as a hash table? Or<br> > perhaps, provide an option to do so. I think it's a pretty common use<br> > case to provide for.<br> ><br> > Thanks again,<br> > Adam<br> <span><font color="#888888"><br> <br> <br> --<br> Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>><br> Assistant Professor / Brigham Young University<br> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br> <br> "The glory of God is Intelligence" - D&C 93<br> ____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> </font></span></blockquote></div></div></div><br><br clear="all"><div class="im"><div><br></div>-- <br>Erik Pearson<br>Adaptations<br>;; web form and function </div></div> <br>____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> <br></blockquote></div><br></div>