[swift-server-dev] Stream priorities & push in HTTPResponse

Tanner Nelson tanner at vapor.codes
Wed Jun 14 06:34:57 CDT 2017


I agree HTTP/2 support should come in the first iteration of this package.

In terms of timing, though, is it possible to come to a consensus on an
HTTP/1.1 API first and then add HTTP/2? In other words, are the features
additive? Or is it pertinent HTTP/2 is a part of the design process for
HTTP/1.1 support? (I'm not as familiar with HTTP/2 as I probably should be
:))
On Wed, Jun 14, 2017 at 12:24 Michael Chiu via swift-server-dev <
swift-server-dev at swift.org> wrote:

> I think server side swift has the advantage being a young server-side
> option and HTTP/2 is basically a must (For example, APNS support only
> HTTP/2 request).
>
> On the other hand, a full HTTP/2 is pretty hard to implement due to it's
> layer violation design, hence we probably can’t even work on it before
> having a solid implementation of stream api.
>
> I don’t think it relate to the matter of swift concurrency api tho, but
> how we manage different connections (probably on the stream level).
>
> Michael.
>
>
> > On Jun 14, 2017, at 4:10 AM, Rien via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > According to wikipedia, market penetration is about 14% for HTTP/2
> servers.
> >
> > Though not necessarily so, it does seem to me that HTTP/2 and a native
> swift concurrency model might go hand in hand?
> >
> > I.e. does it make sense to talk about HTTP/2 support without a native
> Swift concurrency API?
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Balancingrock
> > Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> >
> >
> >
> >
> >
> >
> >
> >> On 14 Jun 2017, at 12:16, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>
> >> Hi,
> >>
> >> one important thing I miss in the current proposal is support for the
> new HTTP/2 features, primarily server push and priorities. We don’t want to
> design for the past, right? :->
> >>
> >> I have no specific proposal on how to do them, but it feels like they
> should be fully interoperable w/ the older versions (if you set either,
> they just get ignored in those setups, or maybe are converted to an x-
> header).
> >>
> >> hh
> >>
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
> _______________________________________________
> 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/c80e323d/attachment.html>


More information about the swift-server-dev mailing list