Re: HSTS Header Duplication
On Thu, Aug 13, 2015 at 6:28 PM, Nick Kew wrote: > On Thu, 13 Aug 2015 20:28:40 + > "Houser, Rick" wrote: > >> Some time back, I turned on HSTS for our sites with something like this: >> >> Header always set Strict-Transport-Security "max-age=###" > > I think you're misunderstanding mod_headers and the headers structure. > In general terms, HTTP permits duplicate headers, which may have > different values. For example,.multiple cookies. So mod_headers > lets you set them, regardless of whether they're already set. > > If that's not what you want, you can of course configure mod_headers > to unset an existing header before setting a new one. Or other > configuration variants. mod_headers already has 'set' vs 'add' so I think his expectation is OK. My first guess would be some issue with headers_out vs err_headers_out ?
Re: HSTS Header Duplication
On Thu, 13 Aug 2015 20:28:40 + "Houser, Rick" wrote: > Some time back, I turned on HSTS for our sites with something like this: > > Header always set Strict-Transport-Security "max-age=###" I think you're misunderstanding mod_headers and the headers structure. In general terms, HTTP permits duplicate headers, which may have different values. For example,.multiple cookies. So mod_headers lets you set them, regardless of whether they're already set. If that's not what you want, you can of course configure mod_headers to unset an existing header before setting a new one. Or other configuration variants. -- Nick Kew
HSTS Header Duplication
Some time back, I turned on HSTS for our sites with something like this: Header always set Strict-Transport-Security "max-age=###" As near as I could tell, everything was working correctly (2.4.12 presently - will be on 2.4.16 shortly). However, one of our development teams recently added a similar HSTS directive into a backend application (which happens to be accessed via mod_cluster). Now, browsers are seeing two different copies of this header on the response (first my values, then the backend values I intended to override). I've verified that direct backend application connections only return one copy of that header. I went back and took a closer look at that various documentation/tutorials scattered around the web for implementing HSTS, and it all seems to indicate "Header always set" for this purpose. I also read the mod_headers documentation several times, but I don't see anything that provides clarity in this case Based on our observations, I suspect that we are looking at a bug of some kind here: either a traditional error in the code or a necessary documentation fix. Would someone please confirm how "Header always set" feature is intended to function (specifically in the presence of an existing header) so I know which direction to research and ultimately submit a patch? Thank you, Rick Houser