- From: Roland Zink <roland@zinks.de>
- Date: Tue, 03 Jun 2014 12:43:33 +0200
- To: Roberto Peon <grmocg@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <538DA6D5.4020201@zinks.de>
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