- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 2 Aug 2016 15:08:37 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
> On 2 Aug 2016, at 3:06 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > In message <ECE83331-ACDD-42E7-B99C-3E4E4C66DD13@mnot.net>, Mark Nottingham wri > tes: > >> Stepping back, I think we're talking about a set of rules something like >> this; > >> A. For a newly defined header field that explicitly uses the new format, >> send it in the new format >> B. For existing header fields, if their expression in the new format is >> defined: >> 1. If you have evidence that your peer can accept the new header >> format, send them in the new format >> 2. Otherwise, send them in the original format. >> C. All other fields are always sent in the original, HTTP/1 format. > > Yes, something like that. > > However, this is digging deep into the extreme far end of the ideas > I presented, and it seems rather too speculative to dig much further. > > I am far more interested in hearing what people think about the > important part of the write-up: Deriving and generalizing a > common header structure from existing HTTP1 header syntaxes ? I think that's the way to go, and that using it for *newly defined* headers is a good enough use case. If we can pause discussion of porting existing headers to the new format for the time being, it may help. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 2 August 2016 13:09:13 UTC