- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 27 Nov 2016 18:38:52 +1100
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Stefan, > On 27 Nov. 2016, at 1:29 am, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > Well, from a server PoV, supporting this for existing headers is not straight forward. Headers can be injected into the response at several stages of processing and some may already be on the wire when the server finds out that a "side-wide" header was changed. Are you talking about handling responses in flight when the .well-known file is updated, or something else? > Servers would need to know the complete set of headers before sending the first one or, alternately, preventing application code to insert such headers from a certain point in time onwards. I am almost certain that this will break some deployments. I think you're over-complicating it. In Apache, .htaccess files don't prevent you from inserting (e.g.) Strict-Transport-Security if CGI or PHP already did so; why is this different? > If the whole purpose - for existing headers - is to save some bytes on the wire, then I find it hard to justify the complexity in these days of h2 and hpack. See the intro of my doc. HPACK has per-connection overhead, so if we keep on adding headers, it's going to get crowded in there, and that takes memory server-side. Doing a .well-known (of whatever flavour) is per-origin, so it takes the pressure off of HPACK. Because it persists beyond a connection, it also means you spend less time at the beginning of each conn setting up HPACK state. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Sunday, 27 November 2016 07:39:29 UTC