[swift-server-dev] Proposal: Strictly-typed HTTPHeader values

[Helge Heß]

On Nov 19, 2017, at 11:35 PM, Amir Abbas Mousavian via swift-server-dev <swift-server-dev at swift.org> wrote:
> We are not changing that underlying `[(String:String)]` architecture

I suppose this is my biggest complaint w/ the PR and why I think it doesn’t belong here.
Either we do typed headers, then the API should vend them as such.
Or we don’t, then such can be part of a different framework.

> These are common headers and every "real framework" have to implement
> this independently!

They could still pull in your `make-headers-nice-my-way` package, if they think it is nice. For the frameworks I’m working on the provided functionality is too high level and not required (I certainly wouldn’t want to parse an Accept into an Array<Enum<String|*>> just to check a match).
So at least for me it is just baggage I don’t need, and I think we’d want to avoid bloat in this specific library.

However, as I said I'm personally in favor of typed headers and would prefer them over Strings a lot. But I don’t have any new arguments which would change the past discussion :-)


Should we have a shared cookie parser? Or an HTTP date parser? I think that would make some sense. But that should be standalone class/type/func which can be applied on a buffer passed in in the context the higher level framework sees fit.
It should not be attached to the response API (how cookies are presented is very framework specific).


> and these accessors are lazy-loaded thus won't impose performance
> overhead on loading. Strict typed storage will hit performance
> significantly and will restrict users to have custom header values.

You are confusing typed headers w/ early parsing. Those are distinct concerns.

The type representing the header value could still decide whether it is better to parse the value very early (e.g. Content-Length), or whether it would do it later (Cookie maybe).

hh