W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Stuck in a train -- reading HTTP/2 draft.

From: James M Snell <jasnell@gmail.com>
Date: Wed, 18 Jun 2014 14:27:26 -0700
Message-ID: <CABP7Rbev-wZYx2tCNyPaSK6t-1FoVh-H9H9bR=TkazY6LZO=wg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mark Nottingham <mnot@mnot.net>, Jason Greene <jason.greene@redhat.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
Yep. Using a variable length encoding 5 bytes is the max we would need for
all practical purposes.

I'm all for dropping Date entirely, tho. That doesn't help us with the
other date headers, but it helps. Last-Modified and If-Modified-Since are
both great candidates for five-byte encoding.

It's too bad the WG didn't pick up on such an obvious improvement but, oh
well I guess.

- James
On Jun 18, 2014 1:36 PM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> In message <
> CABkgnnVT8zGSiU8fDqNtiaL+f2ziBytyP_SUGyPSL2anZf546Q@mail.gmail.com>
> , Martin Thomson writes:
> >On 18 June 2014 13:17, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> >> In that case we should transfer the time as a POSIX time_t in the
> >> HEADERS frame.  Wasting time huffman encoding dates and still
> >> using 24 bytes where 8 would be plenty is just plain stupid.
> >
> >Yeah, that was discussed and rejected, though not permanently.  I
> >think that James worked out that 5 bytes was enough in the short term
> >with a little epoch tweaking.
> >
> >And yes, we are plain stupid.  Think of the cost of parsing that stuff
> >as opposed to doing ntohl().
>
> Indeed.  Ascii Timestamps amount for about 30% if Varnish CPU load :-/
>
> --
> 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.
>
>
Received on Wednesday, 18 June 2014 21:27:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC