So I'm digging into adding HTTP/2 support to some fairly general-purpose server code for sending and receiving large binaries.
One of the features I'd like to preserve, which works well for HTTP 1.x, is giving the application control of when to send the 100-Continue response - so, no HttpObjectAggregator - everything expects to deal in HttpContent or Http2DataFrame on its own. Basically it's code that does a bunch of stuff to ensure a deterministic footprint in the presence of lots of large concurrent requests. So here's what I don't know what to do with: An HTTP/1.1 -> HTTP2 upgrade scenario. There seems to be no way to get to the upgrade handshake without first allowing the payload through. By default, HttpServerUpgradeHandler takes care of this, by extending HttpObjectAggregator, which sends the 101-Continue response. Subclass it to return null from newContinueResponse(), and, at least in testing with curl, the connection times out waiting for the 100 continue response and never gets to the upgrade handshake. Quirk of curl? Something I'm not thinking about right? Or simply unsolvable because for some reason clients should be expected never to attempt the upgrade handshake until the continue response has come and the payload has been delivered - the response can be delivered by HTTP2 but the payload portion of the request must be completed via HTTP1? (that last doesn't make much sense from the standpoint of utilizing HTTP2, but I'm suspecting that's the case). I'm sure I could do some jujitsu to pass the request down through a few layers to let the application layer get to send the 101 or veto the request, but it seems like there ought to be a way to solve it that isn't swimming against the current. Thoughts? -Tim -- You received this message because you are subscribed to the Google Groups "Netty discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/7586e1d5-096d-47f5-8698-d344d367dde9n%40googlegroups.com.
