- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 27 Jun 2014 22:46:53 +0200
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, Johnny Graettinger <jgraettinger@chromium.org>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Jun 27, 2014 at 03:35:29PM -0500, Jason Greene wrote: > > Then probably your and Johnny's choices indicate that there are at least > > two reasonable implementations on the client side. Maybe we could make > > the spec a bit stricter an only allow CONTINUATION frame if a header is > > over 16kB and indicate that it is legal for the recipient to reject them > > in any other case ? That would solve both sides of the problem : > > > > - recipients not interested in supporting more than 16kB do not need > > to implement them - at all - > > > > - there is no incentive for senders to produce them unless absolutely > > necessary, which ensures that recipients who do not implement them > > will never get into trouble below 16kB > > > > Then we're exactly in the same situation we used to face with H/1 which > > is that some implementations which do not support large enough headers > > will simply reject the message, and nothing changes for anyone. > > > > Would that be OK for every one ? > > IMO it doesn?t help that much. If recipients are not going to implement them > then it should be an optional extensional vs an interop mess. It already works like this in H/1 and that's not an issue at all. Basically you find small headers over the net and large ones inside certain corporate environments. Depending on where you deploy, you'll know that some components are suited or not. It already works like this today and products adapt to their target. Willy
Received on Friday, 27 June 2014 20:47:26 UTC