Stream priorities & push in HTTPResponse

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

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: Balancingrock (Rien) · GitHub
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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

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@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: Balancingrock (Rien) · GitHub
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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

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@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@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: Balancingrock (Rien) · GitHub
> 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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

I have no idea what you are talking about. What has the concurrency model to do w/ HTTP?

HTTP/2 has the same request/response model that HTTP/1 has. To the application layer it is completely transparent and adds two main features:

a) Server push. When receiving a request, the server can deliver
   additional responses to the server, as if the server had
   requested them).
   (Note that this has nothing to do w/ ‘Push’ in the traditional
    sense, i.e. the server cannot on its own initiate a new stream
    and talk back to the client.)

b) Stream priorities. I think either side can assign a priority to
   the request/response stream. That way e.g. HTML content can be
   delivered before e.g. images.

For a) we would essentially need API which allows the programmer
to attach additional responses to a request (and only do so if the
protocol supports so, to avoid extra work).
I expect a) to be very useful for API endpoints too.

b) Is a little trickier (you need to perform I/O scheduling which
e.g. GCD channels AFAIK do not support) and I suppose is not widely
implemented. It is optional though, we can do the imp later but
provide the API for it upfront.

hh

···

On 14 Jun 2017, at 13:10, Rien <Rien@Balancingrock.nl> 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?

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?

I have no idea what you are talking about. What has the concurrency model to do w/ HTTP?

I may be using the wrong terminology, please correct me where I am wrong.
I assume that priority assignment involves rescheduling (even cancelling) of tasks and thus also the protection of resources.

HTTP/2 has the same request/response model that HTTP/1 has. To the application layer it is completely transparent and adds two main features:

What do you mean with “completely transparent"?
I was under the impression that the application layer and possibly even the content has to know about HTTP/2 in order to fully utilize it.

Rien.

···

On 14 Jun 2017, at 13:23, Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:
On 14 Jun 2017, at 13:10, Rien <Rien@Balancingrock.nl> wrote:

a) Server push. When receiving a request, the server can deliver
  additional responses to the server, as if the server had
  requested them).
  (Note that this has nothing to do w/ ‘Push’ in the traditional
   sense, i.e. the server cannot on its own initiate a new stream
   and talk back to the client.)

b) Stream priorities. I think either side can assign a priority to
  the request/response stream. That way e.g. HTML content can be
  delivered before e.g. images.

For a) we would essentially need API which allows the programmer
to attach additional responses to a request (and only do so if the
protocol supports so, to avoid extra work).
I expect a) to be very useful for API endpoints too.

b) Is a little trickier (you need to perform I/O scheduling which
e.g. GCD channels AFAIK do not support) and I suppose is not widely
implemented. It is optional though, we can do the imp later but
provide the API for it upfront.

hh

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

I may be using the wrong terminology, please correct me where I am wrong.
I assume that priority assignment involves rescheduling (even cancelling) of tasks and thus also the protection of resources.

Assumptions are not a good thing to base discussions on. May I kindly suggest:

  RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)

Then please formulate which parts of HTTP/2 would require what in the API or concurrency layer and why.

HTTP/2 has the same request/response model that HTTP/1 has. To the application layer it is completely transparent and adds two main features:

What do you mean with “completely transparent”?

In the easy case you get a request and deliver a response which from the API perspective can be identical between HTTP/1 and 2 as the processing model is exactly the same.

I was under the impression that the application layer and possibly even the content has to know about HTTP/2 in order to fully utilize it.

If you want to push resources and change the priority you obviously need API. But you don’t have to do such, they are optional features.

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?

IMO it should be considered _now_. You don’t want to have two APIs when one would be sufficient.
I don’t have the time to make a proper proposal right now, but essentially there would need to be a change in how responses are initiated.
I don’t expect the change to be very complex or difficult, it just needs to be well thought through wrt supporting HTTP/1 and /2.

(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.)

···

On 14 Jun 2017, at 13:41, Rien <Rien@Balancingrock.nl> wrote:
On 14 Jun 2017, at 13:34, Tanner Nelson via swift-server-dev <swift-server-dev@swift.org> wrote:

On 14 Jun 2017, at 13:23, Michael Chiu <hatsuneyuji@icloud.com> wrote:

HTTP/2 is pretty hard to implement

That was mentioned a few times in the past and I don’t really understand why. I don’t think it is particularly hard to implement a working HTTP/2 stack (in a way it is easier because it is a clean binary protocol w/ no legacy).
If you want to implement stream priorities (which are entirely optional), you need a nice I/O scheduler, but that is not required to get started and just icing on the cake.

Or you use nghttp2. Which I don’t think is desirable due to the large amount of dependencies it has (didn’t that use Boost and more?).

And oh, BTW, my mod_swift implementation of the current API just works over HTTP/2 :-)

  GitHub - modswift/http at implementation/mod_swift

hh

Hello, Helge!

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! :blush:

···

On Wed, Jun 14, 2017, 09:25 Helge Heß via swift-server-dev < swift-server-dev@swift.org> wrote:

On 14 Jun 2017, at 13:41, Rien <Rien@Balancingrock.nl> wrote:
> I may be using the wrong terminology, please correct me where I am wrong.
> I assume that priority assignment involves rescheduling (even
cancelling) of tasks and thus also the protection of resources.

Assumptions are not a good thing to base discussions on. May I kindly
suggest:

  RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)

Then please formulate which parts of HTTP/2 would require what in the API
or concurrency layer and why.

>> HTTP/2 has the same request/response model that HTTP/1 has. To the
application layer it is completely transparent and adds two main features:
> What do you mean with “completely transparent”?

In the easy case you get a request and deliver a response which from the
API perspective can be identical between HTTP/1 and 2 as the processing
model is exactly the same.

> I was under the impression that the application layer and possibly even
the content has to know about HTTP/2 in order to fully utilize it.

If you want to push resources and change the priority you obviously need
API. But you don’t have to do such, they are optional features.

On 14 Jun 2017, at 13:34, Tanner Nelson via swift-server-dev < > swift-server-dev@swift.org> wrote:
> 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?

IMO it should be considered _now_. You don’t want to have two APIs when
one would be sufficient.
I don’t have the time to make a proper proposal right now, but essentially
there would need to be a change in how responses are initiated.
I don’t expect the change to be very complex or difficult, it just needs
to be well thought through wrt supporting HTTP/1 and /2.

(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.)

On 14 Jun 2017, at 13:23, Michael Chiu <hatsuneyuji@icloud.com> wrote:
> HTTP/2 is pretty hard to implement

That was mentioned a few times in the past and I don’t really understand
why. I don’t think it is particularly hard to implement a working HTTP/2
stack (in a way it is easier because it is a clean binary protocol w/ no
legacy).
If you want to implement stream priorities (which are entirely optional),
you need a nice I/O scheduler, but that is not required to get started and
just icing on the cake.

Or you use nghttp2. Which I don’t think is desirable due to the large
amount of dependencies it has (didn’t that use Boost and more?).

And oh, BTW, my mod_swift implementation of the current API just works
over HTTP/2 :-)

  GitHub - modswift/http at implementation/mod_swift

hh

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev