Re: "Timeout" request header to tell server to wait for resource to become available

Amos Jeffries <> Mon, 30 March 2015 08:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B91221A9233 for <>; Mon, 30 Mar 2015 01:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RA-ez9JgQ0JJ for <>; Mon, 30 Mar 2015 01:10:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 113B41A916D for <>; Mon, 30 Mar 2015 01:10:37 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YcUiW-00081h-NM for; Mon, 30 Mar 2015 08:06:40 +0000
Resent-Date: Mon, 30 Mar 2015 08:06:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YcUiJ-00080k-V4 for; Mon, 30 Mar 2015 08:06:27 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1YcUiI-0006j3-KH for; Mon, 30 Mar 2015 08:06:27 +0000
Received: from [] ( []) by (Postfix) with ESMTP id A0957E6E46 for <>; Mon, 30 Mar 2015 20:05:52 +1200 (NZST)
Message-ID: <>
Date: Mon, 30 Mar 2015 21:05:52 +1300
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-1.468, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1YcUiI-0006j3-KH 774d09c634207ecb292e1105af049052
Subject: Re: "Timeout" request header to tell server to wait for resource to become available
Archived-At: <>
X-Mailing-List: <> archive/latest/29066
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 30/03/2015 4:34 a.m., Brendan Long wrote:
> I don't think the semantics I want are the same. RFC 7240's "wait"
> indicates how long a client is willing to wait for a server to finish
> processing, but what I'm looking for is a way to tell the server that we
> want it to wait, even though it could respond now.

So... in order to avoid latency of 1*RTT you are requiring to make a
request then have it *not respond* for T seconds.

Meaning the benefits kick in when the RTT > T. For most modern networks
that condition will simply not be true. RTT is generally in the order of
 0.0n seconds (or less).

Particularly given that time to receive the 404 message triggering the
retry just provided the latency value for 1*RTT, and the server reply
can contain Retry-After:T as a header value to complete the client pause

> Maybe the "Wait-Until: available" or "Wait-Until: etags-change" variant
> makes this more clear?
> I don't think millisecond granularity of the timeout is particularly
> important. I picked milliseconds because they're a common unit, but
> seconds would be fine too.

I live in one of the more remote countries in terms of RTT latency and
we only have 350ms worst-case.

Implying the benefits threshold (RTT > T) even in normally bad network
conditions will still not be met.

> The main advantage of setting a timeout in
> the header is that it makes altering clients to support this easier
> (since they'll eventually get a valid response instead of a connection
> error).

And the main disadvantage is that some MBs of memory, and scarce TCP
socket resources are consumed for each HTTP/1 connection that is held
open by this.

Overall I dont see why this has to be a server-wait mechanism instead of
the existing HTTP client-wait mechanism.