[racket] net/http-client

From: Norman Gray (norman at astro.gla.ac.uk)
Date: Tue Sep 17 10:34:33 EDT 2013


On 2013 Sep 17, at 14:51, Jay McCarthy <jay.mccarthy at gmail.com> wrote:

> I think it's an obvious request, but a character flaw of mine is not
> doing things unless they can be done really good. In this case, I see
> a hash table as a "parse" of the headers. It's not obvious to me how
> to parse them. For example...

I don't think that all of these things are necessary, or even obviously desirable, for a 'parse of the headers'.  What I would expect from a parse-headers function would be something that makes available the collection of headers in a convenient way -- that 'lifts it off the wire', if you like -- but I wouldn't expect much more.  Specifically, if I want to deal with semantics (perhaps involving the implications of repeated headers), or if I want to parse the _values_ of headers, I would expect these to be a logically separate operations.

That doesn't rule out providing added-value functions which do the extra work, possibly composed with a core parse-headers function, but a thorough (meaning robust and compliant) implementation of the core part of the job should I think be regarded as 'done well', even if there's a larger bells-and-whistles job that one can envisage.

In particular...

> - The same header can appear many times, so (Key -> Value) is
> incorrect, unless you overwrite one. It would be better to have (Key
> -> (Listof Value)) but that feels really ugly since most of the time
> there will just be one

A core function which returned an alist of the headers, combined with a alist->hash function which (say) concatenated the values of repeated headers, would do the majority of the work in the majority of cases.

I as a user would not grumble at having to do this extra bit of work for those headers which needed it.

(incidentally, I don't recall any HTTP headers which can meaningfully be repeated, and a quick scan of RFC 2616 doesn't remind me of any -- which ones are these?)

> - The spec doesn't mandate case sensitivity on headers, so I would
> need to canonicalize "ACCept-ENCodiNG" to something else. Maybe
> 'Accept-Encoding?

Canonicalising them all to symbols (that is 'accept-encoding and friends) would make this nicely apparent to users.

> - The value of many headers is not really a string. For instance,
> Content-Length is a number, Cache-Control is an association list,
> Content-Disposition is complicated, etc. I feel like it is
> disingenuous to only partial parse.

A (Listof (Cons symbol? string?) would be fine as the return for most cases, leaving the parse of the value for some separate function.  For example get-content-length with (-> (Listof (Cons symbol? string?)) number?).

That's especially true for values which themselves have complicated syntaxes.  I've twice had to parse the rather intricate syntax of the Accept header, and I think I re-did it the second time, rather than re-use my first attempt at it, because the question I wanted to ask of the header was different.  If there had been a parse-accept-header-content function, I would doubtless have used it, but I'm not sure how much real thought it would have saved me.

Or in other words, there's not necessarily a unique best way to parse the more intricate header values.

(I'd be happy to share that Accept parse code if it was useful).


I'm jumping in the the middle of this thread, so apologies if this has already been covered.

Best wishes,


Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK

Posted on the users mailing list.