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

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 19 Jun 2014 18:31:34 +1200
Message-ID: <53A283C6.4030601@treenet.co.nz>
To: ietf-http-wg@w3.org
On 19/06/2014 9:27 a.m., James M Snell wrote:
> 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

How about we proxy people collude and define a proxy SETTINGS extension
to turn on lots of these types of optimizations?
 That way we can turn around and show how slow the client->server direct
traffic format is. At least until they see the light and join in.

Amos

> On Jun 18, 2014 1:36 PM, "Poul-Henning Kamp" 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 Thursday, 19 June 2014 06:32:23 UTC

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