<div><div><div><div><div><div><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:14.000000953674316px">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.</span><br><div><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:14.000000953674316px"><br></span></div><div><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:14.000000953674316px">I implemented my proposal draft in </span><a href="https://github.com/swift-server/http/pull/104" target="_blank">https://github.com/swift-server/http/pull/104</a></div><div><br></div><div>📝 Please note:</div><div dir="auto"><br></div><div dir="auto">- `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.</div></div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div>
</div></div></div></div></div>