On Thu, Mar 12, 2020 at 3:34 PM Martin Grigorov <mgrigo...@apache.org> wrote:
> > > 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! ;-) > Actually, every time you look into some part of Wicket code you find things to improve. Go look into it, Emond! :-) > > >> >> 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 >> > >> >
