Re: T-E chunked trailers

Willy Tarreau <w@1wt.eu> Fri, 10 February 2017 11:43 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279C41289C4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 Feb 2017 03:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPmBnD1FvWRS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 Feb 2017 03:43:32 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1E212949B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 Feb 2017 03:43:32 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cc9Yd-0006sR-OS for ietf-http-wg-dist@listhub.w3.org; Fri, 10 Feb 2017 11:40:07 +0000
Resent-Date: Fri, 10 Feb 2017 11:40:07 +0000
Resent-Message-Id: <E1cc9Yd-0006sR-OS@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <w@1wt.eu>) id 1cc9YY-0005BU-IB for ietf-http-wg@listhub.w3.org; Fri, 10 Feb 2017 11:40:02 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <w@1wt.eu>) id 1cc9YS-0001Jz-GI for ietf-http-wg@w3.org; Fri, 10 Feb 2017 11:39:57 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v1ABdW8h013450; Fri, 10 Feb 2017 12:39:32 +0100
Date: Fri, 10 Feb 2017 12:39:32 +0100
From: Willy Tarreau <w@1wt.eu>
To: Ashok Kumar <ashokkumarj@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20170210113932.GC2932@1wt.eu>
References: <CAOeYYRfye_oX4Vq-TmXrAQpz2LR3Zinw5jjk6kDmYX5vz5Hr3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOeYYRfye_oX4Vq-TmXrAQpz2LR3Zinw5jjk6kDmYX5vz5Hr3g@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=-0.016, BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cc9YS-0001Jz-GI 40313cd8ef4a228a6d5e1544a9433d54
X-Original-To: ietf-http-wg@w3.org
Subject: Re: T-E chunked trailers
Archived-At: <http://www.w3.org/mid/20170210113932.GC2932@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33468
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi,

On Fri, Feb 10, 2017 at 11:56:32AM +0530, Ashok Kumar wrote:
> Hi All,
> 
> rfc7230#section-4.4 talks about the Trailer header for Chunked T-E.
> 
> I need some clarity on expected behavior from server,
> 
> When a User-Agent sends a POST request with Chunked body and includes a
> Trailer header (say with value content-md5) in the request headers, but
> doesn't include any trailers after the zero chunk in the POST body.
> 
> Should this be an error or can this be ignored?

There is no reason why it should be an error, the Trailer header field
only notifies the recipient that it should be prepared to receive trailers.
It is more or less comparable to the Connection header field but for
trailers. However if the recipient absolutely needs this trailer, it's
a different story of course.

> Since none of the mandatory headers can be present, I feel that this can be
> ignored,

You just need the empty line to mark the end of the trailers anyway.

> But on the other hand, content-md5 not getting generated could be some
> middle box modifying the content and stripping off the trailer?

Definitely, or simply stripping it without touching the content. But see
Mark's response regarding this anyway.

Willy