- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 6 Aug 2017 23:26:41 +0800
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Daniel Stenberg <daniel@haxx.se>, Adrien de Croy <adrien@qbik.com>, Willy Tarreau <w@1wt.eu>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On 4 Aug 2017, at 8:15 pm, Cory Benfield <cory@lukasa.co.uk> wrote: > > > >> On 4 Aug 2017, at 08:43, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: >> >> The live, so far, in my test cases for Apache httpd. I'd expect them to get used when the web starts worrying about message integrity more, once the https everywhere thing is done. ;-) > > Adding to the list, HTTP/1.1 trailers are barely supported in the Python ecosystem: none of the major libraries or tools can emit them, and many fail to parse them. The better implementations parse-but-ignore. The Python HTTP/2 stack supports emitting and parsing trailers. This thread makes me wonder if we can't improve things slightly in HTTPtre. E.g., we could say: > A header field MUST NOT appear in trailers unless its definition allows it. Receiving implementations MUST ignore header fields appearing in trailers when their definitions do not allow it. ... with an appropriate column in the header field registry to record this. I don't think this would break any existing implementations, because trailers are so seldom used right now, and I think there's a strong argument that this is the case anyway; the consuming application has to expect something in trailers to act upon it. <https://github.com/httpwg/http11bis/issues/16#issuecomment-320513541> -- Mark Nottingham https://www.mnot.net/
Received on Sunday, 6 August 2017 15:27:10 UTC