Re: #458: Requirements upon proxies for Expect

Willy Tarreau <> Tue, 04 June 2013 06:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEE8621F8F69 for <>; Mon, 3 Jun 2013 23:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Vr51-qXBZcd for <>; Mon, 3 Jun 2013 23:22:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D37521F856D for <>; Mon, 3 Jun 2013 22:16:13 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UjjZ1-0002ko-4p for; Tue, 04 Jun 2013 05:13:43 +0000
Resent-Date: Tue, 04 Jun 2013 05:13:43 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UjjYi-0002iJ-MN for; Tue, 04 Jun 2013 05:13:24 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UjjYh-000847-LB for; Tue, 04 Jun 2013 05:13:24 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r545CxXE013320; Tue, 4 Jun 2013 07:12:59 +0200
Date: Tue, 4 Jun 2013 07:12:59 +0200
From: Willy Tarreau <>
To: Mark Nottingham <>
Cc: " Group" <>
Message-ID: <>
References: <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-1.854, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.511, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UjjYh-000847-LB f4130afd019fc561730730ce9cb1bbe3
Subject: Re: #458: Requirements upon proxies for Expect
Archived-At: <>
X-Mailing-List: <> archive/latest/18165
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Jun 04, 2013 at 11:37:14AM +1000, Mark Nottingham wrote:
> So, you'd like to relax this requirement for all connections, not just when
> the proxy knows that the forward hop is 1.0?

Yes, for three reasons :
  - it's the only way for a content analyser (think anti-virus) to get
    the payload ;
  - clients already expect to receive multiple non-final 100 responses
  - we never know for sure the version of the next hop, and deciding a
    behaviour rule this way could probably introduce more confusion than
    having a general one

> I think that's sensible, but it's a bigger change; what do others think? 

> >> I'd also really like to see us define what "final status code" means; is it
> >> just 417? Any 4xx or 5xx status? Any non-1xx status?
> > 
> > I think that since only 1xx are non-final, final are all other ones, but
> > you're right, we should define this term.
> Anyone disagree with "final" being any non-1xx status code? Note that this
> would allow an origin to respond with 200 OK to a request with an expectation
> in it (when the entire request hasn't yet been received). I think that's OK,
> just wanted to point it out.

Anyway, this is already allowed in some form since we ask the clients to
forward the body is they get no response for a certain amount of time. So
that means that over the wire we can see a final response without a 100/417.
And the most common examples of such final responses I can have that will
not even wait for the body are 401 and 302. The purpose of Expect precisely
is to let the server decide without passing it the payload. If we prevent
the server from asking for authentication without getting the payload, I
think that the usefulness of Expect becomes quite limited.

Best regards,