[RFC] Headers V2

[mseri]

This is not yet an RFC but collects -- in fact, mostly copy-pastes -- some thoughts from @samoht and @dinosaure in the discussion on #747

Since we are breaking the Header module anyway, it seems reasonable to explore if the headers could be turned into an heterogeneous list with typed keys to know if an entry is a list of string of just a string or with even finer types. The goal would be to only have one get function. Something along the lines of:

val content_range : int64 key
val media_type : string
val connection_close : bool
val get: t -> 'a key -> 'a

This could also allow us to address #726 at the same time.

There are a few things to keep in mind.
One is that that the header fields are practically infinitely extensible:

Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification and in many other specifications outside this document set. RFC section 3.2.1

So we should make sure to have a way to have custom string getters that are built from a string and return a string list for the use-cases that require custom headers.

In principle, we could try to auto-generate most of the getters from the list at IANA and if we have a nice library for parsing the various types we could make the headers as type-safe as they can be.

For a concrete example of such a thing, mrmime implements this with the Field module. From direct experience and its usage in several projects (such as ocaml-dkim or ptt), this approach comes with many benefits (the main is to extract values directly to their OCaml form). However, a question remains: which kind of type we want to handle. RFC 5322 defines an exhaustive list of what an email parser should be aware (From, Date, etc.) and mrmime implements only them. I think HTTP should list them too.

If you want to go this way, it requires more (orthogonal) works:

1. implement such type like Content_type.t/Accept_*.t/etc.
2. tweak the underlying list of Header to be a heterogeneous list of GADT constructors
3. handle non-specified values (such as Unstructured for mrmime)

It requires more work about the parser of fields and maybe it's a good time to:

• use Angstrom (as HTTP/AF) and unstrctrd (to be sure to handle any cases)
• or directly use Unstrctrd.of_string

And post-process values with associated parser (the Content-Type parser, the Accept-* parser, etc.).

[mseri]

For a simple angstrom header parser, a bit more strict than ours, we can also have a look at https://github.com/tmattio/dream-encoding