- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 25 Sep 2017 13:52:10 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On Aug 6, 2017, at 8:26 AM, Mark Nottingham <mnot@mnot.net> wrote: > >> 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> We spent an enormous amount of time separating HTTP message processing from required understanding of its semantics. What you describe above is not an improvement. It isn't even implementable, in general. ....Roy
Received on Monday, 25 September 2017 20:52:39 UTC