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
Please note:
- `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.
I think we already discussed this kind of stuff and decided not to do typed headers at this level of the framework. It would be part of a real framework on top of this driver.
If we really go the route of typed headers (which I personally kinda like for efficiency), we should actually do that in the storage itself, not just wrapping the String key/value. I wrote some email on that in the list.
Since `[(String:String)]` seems to be what people decided to use (we discussed that a few times, too), I think this stuff should just live in a separate package (which higher level frameworks can use or not). It far exceeds the minimalist route this thing was trying to go.
hh
···
On 17. Nov 2017, at 17:39, Amir Abbas Mousavian via swift-server-dev <swift-server-dev@swift.org> wrote:
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.
- `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.
Please note: