On 27/04/2021 22:14, Rémy Maucherat wrote:
<snip/>
I remember after doing the rewrite valve I got asked a bit about
mod_headers because "why not". However, now I recall I found out it would
be far less practical. So I very quickly moved on since it was also less
useful than rewrite. I would still probably not do it.
I'm rapidly coming to the same conclusion. Certainly for a pure Filter
approach. And a Valve approach doesn't look much better.
I'm currently mulling over an extension point for the Connector.
responseHeaderValidationClass or similar. Ideas at this point are:
- have one or more callbacks from AbstractProcessor.prepareResponse()
- provide a number of standard implementations
- NO-OP (same as now)
- warn (logs a warning for anything dangerous it finds)
- fix (removes/fixes any invalid headers)
Alternatively, configuration could be nested inside the connector
element which would allow the option for more configuration. We could
still have standard implementations. My expectation is that a suitable
default would be added (probably not NO-OP) if no explicit configuration
was provided.
I'm wondering if there is merit in a Valve-like mechanism for Coyote.
Name TBD but would look something like:
- callbacks
- after request headers are parsed / before the request is prepared
- after the request is prepared
- before response headers are prepared
- after response headers are prepared / before they are written
- allow multiple "Valves" to be configured
- provide a "default" that doesn't require explicit config
- explicit config can add custom "valves", the default "valve" or any
combination
I'm leaning towards the latter approach as it has much greater
flexibility and I can see different users having subtly different
requirements and this avoids an explosion of configuration attributes on
a single class.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
