- From: Yoav Nir <ynir.ietf@gmail.com>
- Date: Mon, 14 Jul 2014 16:02:28 +0300
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jul 14, 2014, at 3:02 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <78AC8C33-6851-4EA2-93D2-1CFD37020F9F@gmail.com>, Yoav Nir writes: > >>> And what exactly would the SHOULD level requirement make anybody do >>> differently anyway ? >> >> It means that if you are creating a client (or server) that supports >> HTTP/2, then you SHOULD be able to work with a server (or client) that >> advertises a 256-byte max-framesize. Otherwise we get two perfectly >> legitimate implementations that fail to interoperate. That's a bad >> thing. > > That SHOULD does not make any sense to me. > > Do you want us to also include SHOULD requirements for 257, 258, > 512, 1024, 1536, 2048 ... ? > > Once you realize that 256 is not magic, your SHOULD requirement > reduces to: > > HTTP/2 implementations SHOULD be able to work with any other > HTTP/2 implementation. > > ...which I really hope we don't need to tell people. We should tell them how. > I also personally have a hard time seeing what I would code differently > to interoperate with a peer announcing 256 as opposed to 16k or 1MB > max frame size: > > frame_size = min(his_settings, my_preference); > > What am I missing ? Down-thread, Jeff asked "So am I to read this as a client might advertise a max frame size of 256 bytes and then request a 2GB file?”, and you answered, "Yes. And the server is free to return 418 or react in any other way” I’m saying that if whenever a client announces 256 some servers will send an error code, we have a problem - we don’t have interoperability. Yoav
Received on Monday, 14 July 2014 13:03:03 UTC