Rémy Maucherat

The plan was to keep the Servlet container implementation classes away from the webapps, so this is a request to do the opposite. It's hard to see how this concept...

@markt-asf If you really want to encourage this, there is the privileged flag on the Context that allows using container servlets. public Request getRequest() { if (request.getContext().getPrivileged()) { return request;...

Ideally, this should be resolved one way or the other by the specification. Also I noticed there is a failCtxIfServletStartFails attribute already, which can easily be abused without too many...

-1 Tomcat covers the most egregious cases, but this is probably not one of them. Even in HTTP/1.1, what the application does setting this connection header is nonsense and will...

Since it's now 2020, shouldn't it be doable to block any attempt to set the connection header by the application ?

I will maintain my -1 For starters, any such HTTP/2 specific nonsense safety nets need to be added to StreamProcessor.prepareHeaders instead of other random locations.

The initial post says SHOULD, but after actually checking the spec it is a MUST. https://tools.ietf.org/html/rfc7540#section-8.1.2.2 It is really odd the specification made such a choice given how many applications...

Still, -1, again for your patch. In addition to being ugly, there's no provision in the Servlet spec to throw an exception on random header names, especially common ones, so...

Yes, it is accurate if there's a "connection: foobar" header, then there could be a "foobar" header and in that case it's tied to the connection header. Note about my...

Indeed, there are two very legacy looking workarounds for brokeness in spnego. One of them can be removed since using Java 8u40 is not reasonable anymore. What about that connection...