W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: CONTINUATION was: #540: "jumbo" frames

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 27 Jun 2014 18:29:53 +1200
Message-ID: <53AD0F61.3040308@treenet.co.nz>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC