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

Re: Interleaving #481 (was Re: Limiting header block size)

From: Roland Zink <roland@zinks.de>
Date: Tue, 03 Jun 2014 12:43:33 +0200
Message-ID: <538DA6D5.4020201@zinks.de>
To: Roberto Peon <grmocg@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
My code checking if only a continuation frame is allowed looks already 
ugly to me but can be extended to allow data frames.

On 03.06.2014 11:35, Roberto Peon wrote:
>
>
>
> On Tue, Jun 3, 2014 at 2:19 AM, Roland Zink <roland@zinks.de 
> <mailto:roland@zinks.de>> wrote:
>
>     On 03.06.2014 11:01, Roberto Peon wrote:
>>     If one does so, then different frames have different max sizes,
>>     and are parsed differently.
>     You seem to assume that the length field needs to have a different
>     length, although I think this isn't really necessary.
>
>
> Welp, I can tell you that we do see headers, especially for responses 
> that are > 64k.
I can tell you that we do see headers that are > 64k, but not many. I 
even have seen a URL > 90 k.
>
>>     This would imply that parsing takes more steps than it does
>>     today, as it would need to examine the frametype, then know the
>>     length of the length-field, then parse the length field.
>     The examination of the frametype is necessary today to detect if
>     it is header / continuation frame and to handle it differently.
>
>
> Not for the basic framing, though-- that is common across all frames. 
> The interpretation of the basic framing does require examination of 
> the fields, but that is a separate (and currently separable) step.
> Anything that eliminates the commonality between frames requires 
> conflating the complexity of interpretation with that of framing.
>
> I'll point out that a non-remuxing proxy can forward frames without 
> modification given the spec today.
It can unless it did header modifications previously.
>
>
>
>>     This is more painful, more codepaths and slower in the common
>>     case/common path.
>     Even better would be if header frames could be handled like other
>     frames and forwarded without much modification.
>
>
> If you're arguing for a 64k limit, then you're saying this will never 
> happen enough that we'd care, and thus almost all the time header 
> frames could be forwarded without modification for a 1:1 proxy.
> If you're arguing that 64k is too little, then you either want every 
> frame's size to be increased, which would likely (as experience has 
> shown) increase muxing latency, or you want to string sequences of 
> frames together as is done with the spec today, or you have different 
> sizes for each frame, which breaks the ability to do basic parsing or 
> dumb inspection.
>
> -=R
>
>
>
>>
>>     -=R
>>
>>
>>     On Tue, Jun 3, 2014 at 1:48 AM, Roland Zink <roland@zinks.de
>>     <mailto:roland@zinks.de>> wrote:
>>
>>         The simple abstraction that headers + continuation can be
>>         treated as a single unit is similar to a single frame.
>>         Wouldn't it be a cleaner abstraction to merge this into one
>>         frame?
>>
>>         Regards,
>>         Roland
>>
>>
>>
>>         On 03.06.2014 01:02, Martin Thomson wrote:
>>
>>             On 22 May 2014 06:13, Michael Sweet <msweet@apple.com
>>             <mailto:msweet@apple.com>> wrote:
>>
>>                 https://github.com/http2/http2-spec/issues/481
>>
>>             Quoting:
>>
>>                 Currently the HTTP2 draft requires that HEADER frames
>>                 be contiguous. Since a header block can be
>>                 arbitrarily large, this presents both an obvious DoS
>>                 vector and a practical issue with streaming
>>                 performance and preservation of the priority scheme
>>                 that HTTP/2 provides.
>>
>>                 A simple solution is to allow intervening DATA frames
>>                 on other, established streams. That will allow
>>                 high-priority data through without major interruptions.
>>
>>             As a DoS vector, the only parties being denied service
>>             are the parties
>>             engaging in the HTTP/2 connection, which is not an issue.
>>              Those
>>             parties have far better means of denying each other
>>             service than this.
>>
>>             The impact on multiplexing is largely congruent with the
>>             above.  The
>>             best response here is "don't do that" with respect to
>>             large header
>>             blocks.  In the worst cases (those in the tail of
>>             Richard's stats),
>>             this is ~64k, which will have those parties adversely
>>             affected.
>>
>>             The only place this is an actual problem is where
>>             messages are merged
>>             from multiple clients (or origin servers) onto a single
>>             connection by
>>             an intermediary.  In those cases, the intermediary is
>>             basically
>>             responsible.
>>
>>             An intermediary can apply policy to prevent this from
>>             happening.  It
>>             seems like many already do this, by setting a limit (8k
>>             being fairly
>>             common).  Other options include putting bad actors into
>>             TIME_WAIT,
>>             putting all bad actors into a separate low bitrate
>>             connection.
>>
>>             The main reason I'm against this change is that it
>>             prevents the sort
>>             of clean abstraction that we currently have, which states
>>             that HEADERS
>>             + *CONTINUATION or PUSH_PROMISE + *CONTINUATION can be
>>             treated as a
>>             single contiguous unit.  An implementation that fails to
>>             apply that
>>             abstraction ends up with the state machine Greg shared
>>             with us in #484
>>             (which is incomplete, BTW).
>>
>>
>>
>>
>
>
Received on Tuesday, 3 June 2014 10:43:58 UTC

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