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

[Helge Heß]

On 25. Nov 2017, at 15:13, Amir Abbas Mousavian via swift-server-dev <swift-server-dev at swift.org> wrote:
> If you think there is a better design, please give a sample or draft.

Well, as mentioned we had the topic of typed headers on this list before and decided not to do them but the String stuff we have now. There is little point in designing something we don’t want :-)

Otherwise I have no new input wrt my email from 2017-11-20. I agree that it might be useful to have and share low-level, standalone parsers for some of the common fields (maybe you could split the PR into the actual parsers and the additions to the types?)
IMO PR-104 is way too much extra. I’m against taking it, but this is really just my personal opinion - the steering team may have a completely different view on this :-)

hh

P.S.: Just to be clear: I think that PR-104 is _one_ valid approach. It just doesn’t belong into this specific layer. HTTP is supposed to be a small and *non-opinioned* framework which can be shared by higher level frameworks. Which then have their own ways to represent stuff like headers to the framework user.

> 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
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev