Re: Rechartering HTTPbis

On 1/27/2012 4:46 PM, David Morris wrote:
> I talked with a hardware vendor yesterday who had implemented an HTTP 
> server and client (and other stuff) in 128KB of ram in a special 
> device. Adding mandatory zlib support would kill his product. 
and mandatory TLS will probably bury it :) (*)

but I don't think extreme ram constraint can be a serious requirement 
for a next generation web transport protocol.

All the folks running computers in their pockets with 4000x that memory 
deserve an experience with always on encryption and compression to deal 
with the high latency mobile world we're looking at.  Just one vendor, 
Apple, shipped 93 million such devices last year .

Making security optional in HTTP/1 has been a disaster (firesheep and 
cookies anyone?). Making compression optional isn't a security disaster 
of course, but it has generally been a giant performance opportunity 
lost. It was all reasonable at the time, but this is a new time. There 
are tail cases where each approach doesn't buy you much, but being able 
to rely on the property (and thus that it won't be unapplied in an 
important case out of convenience, cheapness, whatever) is far more 
important.

-Patrick

(*) it isn't obvious to me that 128KB isn't plenty for the decompress 
format, I suspect the "and other stuff" comment means we should just 
assume the extreme limit for the discussion rather than playing 
name-that-tune with our own guesses at how tightly it can be implemented.

Received on Friday, 27 January 2012 22:42:58 UTC