Re: Striving for Compromise (Consensus?)

In message <>, Nicholas Hurley 

>> >This minimum needs to be bigger, like I've said before. A laughable size
>> >like 256 just provides too much opportunity for someone to shoot
>> themselves
>> >in the face. 4k is still my suggestion here, based on telemetry on
>> >compressed header sizes in Firefox.
>> There are a lot of HTTP traffic never seen by Firefox, for instance
>> "internet of things" gadgets reporting to home-ships.
>Please, tell me more about how I know nothing about anything outside
>Firefox. We've always been looking for hard, technical arguments in these
>discussions, so I made one. I'm still waiting for one of yours.

You said your 4K size was based on firefox "telemetry".

I'm not in any way questioning that you know what firefox is doing
or seing, I'm pointing out that there is a whole universe of HTTP
requests that never get anywhere near Firefox,

If some random http-application doesn't need 4K, there is no rational
reason why we should force them to announce their willingness to
receive 4k frames.

But we should demand that basic HTTP interop will keep working
and in my perception that means that you can "GET /robots.txt"
and get a "I deny everything" entry back, and that you can
"GET /" and get a 3xx response back.

My back of the envelope says 256 bytes can do that, but HPACK
may even allow us to reduce it to 128.

>> The reason to have a minimum size in the first place, is to make
>> sure that you can actually do a "GET /" or "GET /robots.txt" and
>> similar "convention" requests to all servers, all the time.
>> If people configure there server for a 256 size, they get what
>> the deserve.  This is not a error-42 protection measure.
> But we shouldn't make it quite so easy for them to shoot themselves in the face.

We are chartered to write a protocol, not a policy.

If 256 bytes is enough for basic interop, we shouldn't require more.

>And with that, I'm done talking about the "internet of things", which is
>such a vague statement that encompasses such varying capabilities in
>endpoints that it's honestly meaningless to talk about in any real sense.

Too bad for you that they're specifically called out in our charter:

	non-browsers ("HTTP APIs")

Fortunately all we need to know about them is that they use HTTP
and generally use small transactions because they have really
small processors and bandwidths.

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 Friday, 11 July 2014 21:54:23 UTC