[racket] net/http-client

Greetings.

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


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