fix GzipHandler issues with HttpConnector mode enabled on Jetty 9.4

[lachlan-roberts]

for the Jetty 9.4 path the GzipHandler is modifying headers of the base Request.

However this is occurring after the JettyRequestAPIData has already copied the headers and filtered out GAE specific headers from what the application receives, so any modifications to the Request headers by GzipHandler were not seen by the application.

The fix is to insert the GzipHandler before the JettyHttpHandler in the handler chain.

This is not an issue with the Jetty 12 path as both the GzipHandler and the JettyHttpHandler wrap the request to modify the headers.

I added GzipHandlerTest to test this for jetty94, ee8 and ee10 code paths.

[maigovannon]

This is not an issue with the Jetty 12 path as both the GzipHandler and the JettyHttpHandler wrap the request to modify the headers.

Could you explain more on this? I see that the logic in the Jetty12 has the same ordering of handlers as the current order in Jetty9 so how would the ordering not be an issue there? Please explain on what the additional wrapping mentioned does for Jetty 12 which is not done for Jetty9?

In case the ordering there doesn't matter, I feel having the same ordering of handlers can be maintained between the Jetty9 and Jetty12 code for uniformity and readability. Otherwise future readers might get confused.

[maigovannon]

1. Actually even without this logic, a non-AE header should have been added by the line below no? Am I missing something here since the switch is only to certain certain flags and not to prevent addition of fields?
2. If my above statement is wrong and that we still need to have this check, can we please this condition along with that line mentioned there? Just to have a more consistent flow of readability on what all fields are getting added?

[lachlan-roberts]

That is correct, it is still correct without this.

This is just an optimization so that we can skip the rest of the logic in the loop as we know straight away it will not match any of these headers.

[lachlan-roberts]

Could you explain more on this? I see that the logic in the Jetty12 has the same ordering of handlers as the current order in Jetty9 so how would the ordering not be an issue there? Please explain on what the additional wrapping mentioned does for Jetty 12 which is not done for Jetty9?

The Jetty 9.4 handlers have the signature void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response). In the JettyHttpHandler we wrap the request with JettyRequestAPIData, which copies over the headers from the Request baseRequest which can filter out certain private headers so the application can't see them.

The GzipHandler in 9.4 modifies the headers in Request baseRequest, so if the JettyHttpHandler has already run, then the headers have already been copied and no change will be seen by the application when Content-Encoding: gzip is removed.

In Jetty 12 the headers are modified by wrapping the request and overriding getHeaders(). So there is no HttpServletRequest yet just a single Jetty Core request, and both the GzipHandler and the JettyHttpHandler act only on the Jetty core Request. And later in the chain it will reach the WebAppContext will it be converted into a servlet request.

[ludoch]

@maigovannon will do the integration process after final review