HTTP headers are simply defined as a pair of strings. But for many of
headers there is a set of defined values or a structured value. Current
implementation is prone to typo and human errors which will raise
hard-to-debug errors. So I propose to have strictly-typed getters/setters
for frequent ones.
I implemented my proposal draft in
- `Cookie`, `Set-Cookie` and ` Authorization` accessors are not implemented
yet and marked as TODO in source code. Also test cases are not implemented
yet. I will implement them in this or another PR.
- I believe raw string should be accessible by developer thus better to
implement as HTTPHeaders properties rather than typing storage object. This
design allows lazy parsing.
- Some setters are not necessary for a server (marked as Request headers).
I implemented them but we can discuss to remove or having them in portfolio.
- Getter accessors of headers such as Accept-Encoding returns sorted values
according to `q` parameter, thus developer would not need to know exact
value of q parameter imo.
- Validating input values is out of scope. It imposes overhead with little
benefit, e.g. EntryTag.wildcard is not a valid value for eTag, but it won't
be checked by setter. Same situation for contentCache.
- ContentType struct doesn't embed parameters such as charset. I’ve
implemented charset as a separate property `contentCharset` which
manipulates underlying Content-Type. We may revise this design and
implementing a struct which holds other parameters too.