On Wed, Nov 11, 2015 at 11:30 AM, Brad Hill <hillbrad@gmail.com> wrote: > A nice benefit of the priming approach for HSTS is that you do receive a > durable signal which the browser can cache, > HSTS is cached for the entire origin, regardless of which resource it comes from. > and which can prevent downgrade attacks on subsequent connections. > This is the same in both approaches. > Also consider that some sites may not set HSTS for every response, but > only for well-known app "entry points" (to optimize network traffic). > Does this still matter, performance-wise, for HTTP/2 connections, given header compression? Just send the HSTS header for all resources for HTTP/2 connections and rely on compression to work. Browsers that would support HSTS priming also support HTTP/2 and HTTP/2 header compression. Conversely, consider a server that never expects a request to "/" and so never sets the HSTS header field (e.g. because it forgot to put the HSTS header field on its error responses, which is a very common failure mode). Also, consider that many servers don't implement HEAD correctly. Cheers, Brian -- https://briansmith.org/
Received on Wednesday, 11 November 2015 21:36:05 UTC