Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt

[Mark Nottingham <[e-mail]>]

> On 28 Nov. 2016, at 3:22 am, Stefan Eissing <[e-mail]> wrote:
> 
> Hi Mark,
> 
>> Am 27.11.2016 um 08:38 schrieb Mark Nottingham <[e-mail]>:
>> 
>> Hi Stefan,
>> 
>>> On 27 Nov. 2016, at 1:29 am, Stefan Eissing <[e-mail]> 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?
> 
> I was thinking of someone at the end of the request output filtering adding a header like access-control-allow-origin. It might be mistaken, but that header only allows a single value.
> 
> If there is the same header in the well-known site-wide definition, it would cause a problem, it seems to me. The client appends the sh headers and sees duplicate values, right?

Yep. My thinking is that this is no different than any other potential clash caused by a configuration mechanism -- the solution is "don't do that."


>>> 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.
> 
> I agree with the goal of this spec. I am not certain it will work for all headers listed. There are obvious once where it does and others, with the example above, where it might not be straightforward. 

We definitely need to go through the headers and evaluate each one, no matter what mechanism we choose.

Cheers,


--
Mark Nottingham   https://www.mnot.net/