Closed zostay closed 9 years ago
Yeah HTTP/2 is a whole other can of worms. It might be worth checking out how Go's HTTP/2 library handles it... my understanding is that if you are using the existing http lib, you can simply swap in http2 and "it just works." So it seems that it can operate in a way where many of the low level details are hidden from the user.
I think in the general case, we want to make whether it's HTTP/1.0, 1.1, or 2 transparent to the application developer, but I think it's likely we'll need to provide some mechanism for tighter control for applications that need it. I don't know what that means for request handling, but for response handling it may mean that we allow the application to emit hashes or arrays of pairs or something to configure the specific frames being sent. If so, we may need a way for the application to receive frames in the same way.
I'm pretty sure we don't want the application to worry about the details of HTTP/2 connection negotiation. That seems pretty firmly a server issue.
Also an HTTP/2 application can push data over an existing connection before the application requests it and an advanced app may want to handle multiple requests all at once.
I have added the ability for headers to be sent via List of Pairs on the payload supply. This allows for trailing headers to be sent as part of an HTTP/1.1 or HTTP/2 response without requiring the application to know which it is. The app server is able to process data frames how it needs at that point.
More work needs to be done to consider the consequences of HTTP/2. Do we want applications to be able to specify which frames to send? Does that even make sense? How do we do that, if so? What happens if an application sends frames, but the application server connection is only HTTP/1.1 or something else? Deep thoughts.