On Thu, Mar 12, 2020 at 3:03 PM Emond Papegaaij <emond.papega...@gmail.com> wrote:
> Hi Sven, > > Yes, you might be right. When rendering another page, normally the > header will be overridden when the second handler is resolved. > However, this will not happen when the page is not protected > (protectedPageFilter). Do you see a solution for this? Maybe recording > the desired action in the RequestCycle per handler, so the last > handler will always override the previous one? The action can then be > performed in onEndRequest. It would be nice if we had some tests for > this, but I'm not that experienced in writing tests with WicketTester > :) > One is never too old to learn how to write tests with WicketTester! ;-) > > Setting the header on a resource usually doesn't make sense, but > doesn't hurt either. I haven't found a clear explanation of how CSP > values interact across requests. For example, for js you can use > strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded > via js. > > Best regards, > Emond > > On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <s...@meiers.net> wrote: > > > > Hi Emond, > > > > it seems to me the CSPRequestCycleListener might add CSP headers > > prematurely. > > > > What if a request comes in for one page and another page is rendered in > > response? > > The listener will already add the headers when the request handler is > > resolved for the former page. > > > > What if the page streams back a resource? Setting the headers doesn't > > make sense then, does it? > > > > Sven > > >
