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

"Poul-Henning Kamp" <> Thu, 17 November 2016 10:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80194129645 for <>; Thu, 17 Nov 2016 02:25:10 -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 wSXechYw-1np for <>; Thu, 17 Nov 2016 02:25:08 -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 8AD2E129874 for <>; Thu, 17 Nov 2016 02:25:04 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c7Jp3-0003g6-3Z for; Thu, 17 Nov 2016 10:21:37 +0000
Resent-Date: Thu, 17 Nov 2016 10:21:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c7Jox-0003d3-9z for; Thu, 17 Nov 2016 10:21:31 +0000
Received: from ([]) by with esmtp (Exim 4.84_2) (envelope-from <>) id 1c7Jor-0001Wo-8X for; Thu, 17 Nov 2016 10:21:26 +0000
Received: from (unknown []) by (Postfix) with ESMTP id 7E3B5273E2; Thu, 17 Nov 2016 10:21:02 +0000 (UTC)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id uAHAL1Rc083651; Thu, 17 Nov 2016 10:21:01 GMT (envelope-from
To: Kazuho Oku <>
cc: Willy Tarreau <>, HTTP Working Group <>
In-reply-to: <>
From: Poul-Henning Kamp <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2016 10:21:01 +0000
Message-ID: <>
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=0.009, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.899, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c7Jor-0001Wo-8X c531143d1c89bd76546de66857501541
Subject: Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)
Archived-At: <>
X-Mailing-List: <> archive/latest/32927
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

In message <>
, Kazuho Oku writes:

>For example, consider the case in which I am writing a draft that
>passes an integer using Common Structure.
>Since Common Structure allows an integral number to be sent with a
>dot, a sender is permitted to send 100 as '100.00'

So this is clearly something the draft needs to explain better.

CS does not decide what values are legal and which are not, it only
helps you transport values safely across the wire.

When you define your header you define the kind of values it accepts,
and if you say that "value X is an integer", it should be pretty
obvious to anybody that sending it as "100.0" is not OK.

If you think people will not get that fine detail right, you can
add text to your header definition which drives the point home.

>you would need to decode a floating point number even in the case
>where you only need to deal with integers.

So this brings up an interesting efficiency detail related to the
HTTP1 serialization:

You cannot tell the difference between an identifier and a number
by looking at the data on the wire, because RFC7230::token allows
both DIGIT, "." and "-".

Your parser will therefore initially classify any "number" as
"identifier", and only once your application code tells it that it
expects an integer, will that string be interpreted as a number.

That means that no numeric processing needs to happen until it
is unavoidable.

(Any design I can imagine for a future HPACK/H3 semantic compression
will have the same property.)

As I hint in 7.2 as "Future work", having the individual headers
defined in a machine readble format (a "schema") would allow us to
use programs to generate combined CS parser+validator for such a

However, history is particularly unkind to that concept, so I
left it in "Future work" and I think we should leave it there
for now.

>My understanding is that most (if not all) headers that will use
>Common Structure would need to encode floating point numbers.

I don't think so.

First, just because they look like floating point numbers in the
H1 serialization, doesn't mean you have to process them as IEEE754
in your application.

If I recall right, the q= weights can be processed as integer
"milli-q", and still be compliant.  In reality comparison of q=
weights is very often done as strings.

Second, apart from q= and possibly future timestamps, I don't see
much call for fractional numbers anyhow[1].

All that said, it probably does makes good sense to have "integer"
as a special case of "number", like "ascii_string" is a subset of
"unicode_string", because it will make it easier for people
to specify their HTTP headers.


[1]  Somebody will undoubtedly use them for monetary values, but I
     have a hard time seeing that make it into a published RFC for
     many reasons.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.