Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)

Willy Tarreau <> Thu, 17 November 2016 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0239F1296B4 for <>; Thu, 17 Nov 2016 02:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zq644MLkejqF for <>; Thu, 17 Nov 2016 02:21:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A515129641 for <>; Thu, 17 Nov 2016 02:21:28 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c7Jle-0001mS-S7 for; Thu, 17 Nov 2016 10:18:06 +0000
Resent-Date: Thu, 17 Nov 2016 10:18:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c7Jla-0001l8-1U for; Thu, 17 Nov 2016 10:18:02 +0000
Received: from ([] by with esmtp (Exim 4.84_2) (envelope-from <>) id 1c7JlT-0001OM-Pa for; Thu, 17 Nov 2016 10:17:56 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id uAHAHRXf010097; Thu, 17 Nov 2016 11:17:27 +0100
Date: Thu, 17 Nov 2016 11:17:27 +0100
From: Willy Tarreau <>
To: Poul-Henning Kamp <>
Cc: Julian Reschke <>, Kazuho Oku <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.575, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c7JlT-0001OM-Pa 40ba5b9d6583d9841d7be51cf8b74f26
Subject: Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)
Archived-At: <>
X-Mailing-List: <> archive/latest/32926
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Nov 17, 2016 at 09:48:16AM +0000, Poul-Henning Kamp wrote:
> >On the other hand most of the time we don't care about the sub-microsecond
> >accuracy,
> Trust me:  We will never care about *timestamps* with sub-microsecond
> resolution in HTTP headers. They barely make sense in the first
> place and transmission noise and and delays will totally swamp any
> information they might carry.

That's inexact, I've already seen people using timestamps as an easy
way to have unique IDs. Of course that's wrong but when the principle
is that once you're cycle-accurate you know you can't do two things
at once, it works as long as you don't have time jumps.

Note I'm *not* defending this misuse and not even advocating for
supporting it. I'm just saying that it's untrue that nobody cares.

> >Or maybe Poul-Henning's 15-digit number can solve it as well. But we must not
> >use it for any number as it would remove the ability to pass 64-bit integers.
> 15 digits is enough for a Content-Length of a petabyte, I don't think
> anybody, now or in the future, will find that a sensible thing to do.

Well it's only one day of traffic at 100 Gbps, it could conceivably be
used after the next decade for file system replication over HTTP. And
if you manage a flat filesystem, you possibly at least want to be able
to use more than this in the Range header to seek on your storage.
There's nothing wrong with asking for one GB of data starting at 1.23 PB.
Multi-petabyte filesystem are still not common but I do know people who
use some already, especially in web hosting (and I'm pretty sure you
know some as well). We clearly see that the boundary between web and
storage sometimes is very thin and we must not prevent solutions from
emerging just because of protocol limitations.

> If you want to move cryptographic bits, there is a dedicated "blob"
> datatype for that.