Re: mod_headers as a Filter

[Mark Thomas <ma...@apache.org>]

On 07/05/2021 09:33, Rémy Maucherat wrote:
> On Wed, Apr 28, 2021 at 10:45 AM Rémy Maucherat <re...@apache.org> wrote:
> 
>> On Wed, Apr 28, 2021 at 9:07 AM Mark Thomas <ma...@apache.org> wrote:
>>
>>> 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 thought about it quite a bit in the past, an interceptor [resurrecting
>> the old name] could be a solution to a lot of problems here. So why not.
>>
> 
> Thinking about it some more, I would propose investigating either:
> - Adding a new interface in addition to ActionHook to coyote.Request, maybe
> called EventHook (gets a code and the request object).
> - Allowing more than one ActionHook [the codes include plenty of the
> interesting events already especially commit, flush]. User configured hooks
> would be added and called *before* the main coyote hook (obviously).
> Although this sounds easier to implement, this is tricker and error prone
> as the call patterns are funky (also the hook field is duplicated between
> request and response likely for no good reason); basically I would say all
> hook action calls would now go through a helper method on the Request.
> - Something else ;)

I think a new interface would be cleaner. Some sort of CoyoteListener 
configured as elements nested under the Connector.

Looking into the history of ActionHook, it looks like the intention was 
to enable support for custom actions for custom Connectors. I don't 
think that was ever used. I switched it to an Enum ages ago mainly as I 
was concerned that, with the growing numbers of actions, some Processors 
may not be implementing all the actions they needed to.

Given that we can now define default method implementations in an 
interface, I think I prefer an interface with one method per event type 
rather than a single method with a parameter that indicates the event type.

Your email also got me wondering whether it was time to refactor the 
Coyote code to remove ActionHook entirely.

I think I have some experimenting to do.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: mod_headers as a Filter

[Rémy Maucherat <re...@apache.org>]

On Wed, Jun 23, 2021 at 8:43 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 07/05/2021 09:33, Rémy Maucherat wrote:
> > On Wed, Apr 28, 2021 at 10:45 AM Rémy Maucherat <re...@apache.org> wrote:
> >
> >> On Wed, Apr 28, 2021 at 9:07 AM Mark Thomas <ma...@apache.org> wrote:
> >>
> >>> 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 thought about it quite a bit in the past, an interceptor [resurrecting
> >> the old name] could be a solution to a lot of problems here. So why not.
> >>
> >
> > Thinking about it some more, I would propose investigating either:
> > - Adding a new interface in addition to ActionHook to coyote.Request, maybe
> > called EventHook (gets a code and the request object).
> > - Allowing more than one ActionHook [the codes include plenty of the
> > interesting events already especially commit, flush]. User configured hooks
> > would be added and called *before* the main coyote hook (obviously).
> > Although this sounds easier to implement, this is tricker and error prone
> > as the call patterns are funky (also the hook field is duplicated between
> > request and response likely for no good reason); basically I would say all
> > hook action calls would now go through a helper method on the Request.
> > - Something else ;)
>
> I think a new interface would be cleaner. Some sort of CoyoteListener
> configured as elements nested under the Connector.
>
> Looking into the history of ActionHook, it looks like the intention was
> to enable support for custom actions for custom Connectors. I don't
> think that was ever used. I switched it to an Enum ages ago mainly as I
> was concerned that, with the growing numbers of actions, some Processors
> may not be implementing all the actions they needed to.
>
> Given that we can now define default method implementations in an
> interface, I think I prefer an interface with one method per event type
> rather than a single method with a parameter that indicates the event type.

Ok, no problem with that plan.

>
> Your email also got me wondering whether it was time to refactor the
> Coyote code to remove ActionHook entirely.

Ok, otoh that's probably not going to bring much value.

Rémy

>
> I think I have some experimenting to do.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org