- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 14 Jun 2017 16:51:05 +0100
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Cc: phk@freebsd.dk
Picking this thread back up, my personal (not chair) observations... I'd thought that the purpose of surveying existing headers in the draft was to learn commonly used structures, so as to help make what we come up more familiar (and thus easier to use), not to come up with something that will replace existing header definitions. To me, the most important thing we're doing here is creating tools / guidelines for authors of *new* header fields to use, so that they don't a) fall into the many pitfalls of doing so, and b) reduce work/problems for implementers when generating/processing those headers. (b) very well may involve specifying syntax. Future consolidation of existing headers is a nice-to-have, but as discussed quite a bit, may require some awkwardness that makes it undesirable. My understanding was that this was a non-goal for this work. Likewise, creating another header serialisation / compression that takes advantage of what we do is something we should keep an eye on, but isn't an immediate goal. I don't *think* there's anything new above; it was discussed quite a bit in the threads leading up to PHK's draft (which AFAICT we adopted because it was going in a non-JSON direction). However, it seems like we're drifting back into that discussion again. Chair hat back on -- Please discuss. We've gone back and forth significantly on this, so it'd be good to get a crisp set of goals that we can agree to in the draft. Cheers, > On 26 Apr 2017, at 1:04 pm, Amos Jeffries <squid3@treenet.co.nz> wrote: > > On 26/04/17 11:16, Matthew Kerwin wrote: >> >> >> On 26 April 2017 at 07:43, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> -------- >> In message <99c23bc4-069e-fd33-5b48-0942e0708d31@treenet.co.nz>, Amos Jeffries >> writes: >> >> >Reading section 7.1 I am wondering if this is significant enough to use >> >HTTP/1.2 version number for 1.x agents as the signal that the sender can >> >receive any header in self-describing Common Structure. >> >> That's an interesting question... >> >> >> ​Very interesting. The request line is a hop-by-hop message, right? So it couldn't be used as a signal for end-to-end headers. > > I'm thinking that headers affected by this signal would have a 'legacy' format - for example Date. So this use-case would be hop-by-hop opportunistic performance optimization. Any agent using it would need to be able to map. > >> How many middleboxen out there are likely to inspect the request line only as far as 'HTTP_VERSION > 1.0' and then barf if one of their response headers looks weird? Although I suppose the answer is not that different from: how many will forward X-Accept-Fancy-Headers blindly and then barf... Pity there was no strong hop-by-hop vs end-to-end flag on headers. >> >> Cheers >> -- >> Matthew Kerwin >> http://matthew.kerwin.net.au/ > -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 14 June 2017 15:51:50 UTC