Could a change like that break other implementations?
This is one of those kinds of changes that is forced on the jakarta specs and their implementations by the industry.
There is no HTTP/2 implementation that supports renegotiation or post-handshake.
Those are specifically called out in the HTTP/2 spec as error conditions if any step (client, server, proxy, load balancers, and any other intermediary) sees them attempted to be used.
The spec pretty much tells you that you must fail the connection (and then explains how to fail the connection properly).
HTTP/2 also changed how a specific http exchange (request/response) can handle error conditions mid-stream.
Example: a response can be started to be sent, but due to an error the rest of the response cannot be sent.
In HTTP/1.1 all you can do is close the connection, which itself doesn't mean anything, and there's no way for the client to really know (simply from the protocol's point of view) that the entire response wasn't sent.
In HTTP/2 that stream has a GO_AWAY frame that can be used to indicate a failure of that stream.
This would be a great thing to expose on the Servlet spec for those uses using HTTP/2. (and if you look around, it's been hacked into various servlet containers by abusing ambiguity in the servlet spec, all in incompatible ways that the TCK never tests for).
- Joakim
