[swift-server-dev] Convert HTTPVersion to struct

[Tanner Nelson]

On Wed, Jun 14, 2017 at 2:11 PM Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

> On 14 Jun 2017, at 14:59, Paulo Faria <paulo at zewo.io> wrote:
> > You're completely right we should care about HTTP 2.0 now. But let's do
> it one step at a time, or else we won't get things done. The current topic
> is the HTTPVersion type. So could you please give your feedback in the
> HTTPVersion thread about how the current proposal of HTTPversion fits with
> HTTP 2.0? We should go from lower abstractions to higher abstractions
> incrementally but definitely considering the upper abstractions. Let's keep
> focus and move on! 😊
>
> I gave my feedback on the type in the this thread already. Struct is fine
> for me, tuple is OK too. I don’t actually care much as “The HTTP version
> should only matter for logging purposes”. If it comes with comparison
> operations and such, something is likely wrong with the API.
>
>
> The only HTTP/2 specific note I have is this thing:
>
>   From the HTTPRequest API design perspective there is a small
>   change in that method/version are just headers in HTTP/2.
>   I brought that up before.
>   E.g. why does ‘method' deserve a special enum, but not
>   content-type etc which is equally important for dispatching
>   a request. Either approach is fine though.)
>

In that case, maybe we ditch the version and method properties in favor of
something more generic like:

(just spitballing some pseudo swift here)
```swift

    struct Request {
        ...
        enum Metadata {
            case original(major: Int, minor: Int, Method)
            case headers
        }

        var metadata: Metadata
        ...
    }


    extension Request {
        var method: Method {
            switch metadata {
            case .original(_, _, let method):
                return method
            case .headers:
                return Method(rawValue: headers["Method"])
            }
        }
    }

```
Here an enum's ability to exhaustively switch would be useful. Then
`req.method` is implemented as an extension similar to how `req.version`
and `req.contentType` could be implemented.


> This affects the discussion as it may make sense to expose the
> HTTPVersion as a regular header to mirror the new HTTP/2 setup
> instead of basing the API on the old HTTP/0,1 model.
> (I think either is fine, with a slight preference for going
>  with the ‘future’)
>
> Or in other words: Why struct or tuple, just keep it as a string
> like the other headers.
>
> If HTTPVersion is not exposed as a String but as a specific type,
> that would then affect the way headers in general are handled
> (and I’m very much in favour of NOT using strings for the common
>  ones for various reasons).
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170614/3962416a/attachment.html>