Re: Striving for Compromise (Consensus?)

On Fri, Jul 11, 2014 at 1:07 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <CANV5PPXaPUGEJWvSgAo2ftX82AL5Gqch1NnYVYXm7pP9N=
> k42A@mail.gmail.com>
> , Nicholas Hurley writes:
>
> >> > 1c) ...with some minimum (which might be 256, though a 256 byte frame
> >> could be all padding...)
> >
> >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.


> For these kind of applications 256 will be plenty.
>

And for those kind of applications, they are more than welcome to make a
convention in their implementation that they never send more than 256.
Saying the minimum max frame size is 4k is not the same as saying you must
send 4k in every frame.


> 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.

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.
--
Peace,
  -Nick