- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 27 Jun 2014 18:29:53 +1200
- To: ietf-http-wg@w3.org
On 27/06/2014 2:22 p.m., Martin Thomson wrote: > On 26 June 2014 16:33, K.Morgan wrote: >> Nobody is arguing against support. If jumbo data frames should be an extension, so should jumbo header frames (i.e. CONTINUATION). > > There's a fairly straightforward calculus. > > Can HTTP do X -> HTTP/2 MUST do X. HTTP can produce a valid response for: ## telnet example.com 80\n . *\n HTTP/2 already cannot even make the request. > > So, can HTTP/2 carry arbitrary amounts of data: yes. The debate there > is about efficiency. That's very different. > > It's different with headers. If we cap header size, then it becomes > literally impossible to make some requests. HTTP/1.1 header size is capped at 64KB by Squid. Other implementators previously stated 4KB, 8KB and 16KB caps. What is new? Ability to announce and negotiate a size will be added benefit for HTTP/2 if accepted. > >> you can't unilaterally get rid of *transfer-encoding*, I can provide ample evidence that t-e is, in your words, "sometimes used". > > I'd rather not re-open that debate, but I think that your concern with > transfer-encoding fixates on the means and not the capability. > Whereas retaining CONTINUATION and rejecting jumbo-HEADER extension is not fixating on one means ? Something smells fishy there. Amos
Received on Friday, 27 June 2014 06:30:26 UTC