Closed craff closed 1 year ago
I think it's probably overkill. I like the simplicity of current's structure :), and that it's easy to give a list of pairs.
I might be amenable to string Map.Make(String).t
as the structure.
I think another idea would be;
For request header some callbacks called for specific keys, avoiding searching the headers. Call backs could be organised in a tree. This would handle for instance cookies, keep_alive, etc ...
For response a bunch of function to set the most used headers.
I think you can close this issue... I still believe we could improve parsing/handling of headers and cookies, but I don't think I will be working on that soon.
I don't think we need something more complicated.
Headers may have much more that 10 fields and usually use common headers (see []https://en.wikipedia.org/wiki/List_of_HTTP_header_field])
We could encode headerfield as type header_field = | Connection : 'a header_field | Content_type : 'a header_field | Cookie : Request.t header_field | Set-cookie : Response.t header_field | ... | Other : string -> 'a header_field
and the headers itself as a hashtable or other data structure a bit more efficient that association list ? Not clear to me what is the best data structure for medium size maps.