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

[Amir Abbas Mousavian]

There is no way to have a typed dictionary in swift, I'm afraid.
Unless we store data as [String: [Any]] and developers have to take
responsibility of down-casting, which is not a good and practical
design imo. Or there is something new in Swift which I'm not aware of.
If you think there is a better design, please give a sample or draft.

Another issue with typed storage is - as I noted before - performance
of converting and casting. It must be lazy and not being part of
initializer or append/replace methods. Furthermore, having a
string-based storage gives much more flexibility to developer.

I believe this framework should implement every aspect regard
transport layer and parsing, and allows other frameworks to implement
logic instead of working with raw data. Additionally, integrating
typed header values as properties keeps room for further
optimizations.

Making data and cookie parsers public is a separate issue. We can
discuss about them. We can make current implementation public anytime.

On Mon, Nov 20, 2017 at 2:51 AM, Helge Heß via swift-server-dev
<swift-server-dev at swift.org> wrote:
> 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