[erlang-questions] What lib to use for http requests

[Loïc Hoguin]

On 12/15/2014 01:17 AM, Fred Hebert wrote:
> On 12/14, Eric Pailleau wrote:
>> Hi,
>> ok but RFC 2616 or 2817 ? (or even historical 1945 ?)
>
> By the way you also have RFCs 7230..7235 now, superseding the two previous
> HTTP/1.1 versions. (not sure if anyone would have wanted the 26 drafts
> in between too: http://trac.tools.ietf.org/wg/httpbis/trac/browser#draft-ietf-httpbis)
>
> Best of luck to whoever decides to go for literal RFC support for this.

It's a little more than those 6, there's a number of other RFCs still 
standing (PATCH for example) and some others released since (like the 
one adding a new redirect status code).

The RFC723x ones are much better though, they don't leave much room for 
interpretation (though some things are still undefined) so 
implementations following them should be much more compatible.

I am currently working my way through the parsing of HTTP headers from 
RFC7230 and RFC7231, making it more precise and more efficient than 
previous Cowboy code, and well tested using Triq.

I believe this, and most of the code in Cowlib, would benefit httpc 
users, as I don't think httpc comes with header parsing functions and 
the like. The drawback though is that httpc uses strings, so it needs to 
convert values to binary first. But it'd still be possible for users of 
most project to depend on Cowlib and start using the parsing functions 
there. They're fairly straightforward too I think:

   cow_http_hd:parse_content_type(ContentType)

The parsing code was detached from Cowboy into a separate library so 
that it could be shared between projects, so there should be no problem 
for other projects using it.

It *is* parsing code only though. The logic code and interface is where 
projects would differ the most so it makes little sense to try to 
abstract those. For example a proxy server needs to follow different 
rules than a plain origin server (including some parsing rules, as 
baffling as that is). And origin servers can have entirely different 
purposes too.

-- 
Loïc Hoguin
http://ninenines.eu