- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 20 Mar 2020 08:55:56 +1100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@greenbytes.de>, Roy Fielding <fielding@gbiv.com>
> On 20 Mar 2020, at 3:44 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > In message <CF788613-EEE1-4321-BE98-780E7C77F607@mnot.net>, Mark Nottingham wri > tes: > >> A little while back we made some changes in http-core regarding >> terminology and headers. This seems to have caused some confusion and >> comment, so I thought I'd summarise where I think we're at (Julian and >> Roy might want to chime in if they feel differently or want to add >> nuance). > > I appreciate that you are trying to disambiguate the confusion brought > about by headers being put in trailers. Thanks, but most of the focus here is disambiguating the various meanings of "headers", regardless of trailers. > However, given that we have talked about trailers for 20+ years > now, yet they have never gained any serious traction, the simplest > and most efficient way to end the confusion is to do away with > trailers, so that headers only live in headers, as originally > intended. > > The problems trailers were invented to work around, are barely > relevant these days, and almost universally handled with JS on the > client. > > We are not running out of headers, so trailers do not enjoy a > "insurance for the future" status like IPv6 did during its > twenty years of crossing of the desert. > > KISS: Trailers must die. That's been discussed quite a bit before, and given that trailers are starting to be both used and reasonably well-supported, it's probably not the time to start that discussion again. The good news is that any implementation can just drop them on the floor if it doesn't want to deal with them; the most they're required to do is to maintain message framing. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 19 March 2020 21:56:17 UTC