Isnt the response buffer size giving a sufficient hint or callback like (dont rewrite before it is reached or body starts to be read)? Guess filter must force some size if not set but sounds like something to check, no?
Le mar. 27 avr. 2021 à 21:32, Raymond Augé <raymond.a...@liferay.com.invalid> a écrit : > Couldn't you add a callback/hook to commit() impl and trigger the rules > during that callback/hook? > > But with that the filter is merely a shell for pushing rules into that > callback/hook registry. > > - Ray > > On Tue, Apr 27, 2021 at 1:04 PM Mark Thomas <ma...@apache.org> wrote: > > > Hi all, > > > > I've started to look at this and I am struggling to see a way to > > implement something that looks like mod_headers as a Filter. > > > > Request headers are fairly simple. The process looks something like: > > a) take a copy of all the headers received > > b) apply all the rules for request headers > > c) wrap the request, overriding the various getHeader... methods and > > return values appropriate for the modified set of headers > > > > Response headers are where I am currently stuck. > > A similar model to request headers might look like: > > a) wrap the response > > b) intercept all the headers set by the application > > c) apply all the rules for response headers > > d) call the appropriate setHeader... methods on the wrapped response > > for the modified set of headers > > > > The problem is that d) (and hence c) needs to be done immediately before > > the response is committed and - short of buffering the entire response > > body - there is no way to know when that is going to happen. > > > > Is the answer we need to buffer the entire response body? > > > > Any cunning ideas on how to detect (in a Filter or wrapped response) > > that the response is about to be committed? > > > > I guess we could try and track bytes (about to be) written and compare > > that to the known buffer size. That seems a little fragile on first > > impression. > > > > Another option is to abandon the mod_headers clone aim and do something > > simpler along the lines of blocking applications from setting specific > > headers and/or header/value combinations. > > > > Thoughts? > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow >
