If headers/metadata isn't flow controlled, then it becomes possible to create an infinite queue on a proxy, e.g. infinite zero-length messages. If one wishes for an ability for a receiver to stop receiving messages, then the headers themselves need to be flow controlled. One way of accomplishing it, which I tried to allude to ( =] ) was that a headers-like-frame which was guaranteed not to use stateful opcodes could be serialized as data (i.e. subject to flow control). Another way of accomplishing it is to have every message require at least a byte of data. -=R On Wed, Dec 3, 2014 at 9:18 AM, Brad Fitzpatrick <brad@danga.com> wrote: > Roberto, what's the motivation for flow-controlled headers? If every WS > message's DATA frame(s) is preceded by a HEADERS to say whether it's JSON > or binary, and DATA are flow controlled, doesn't that mean there's at most > one HEADERS that sneaks by without flow controlled when the peer wants the > other to stop sending? Is it that one small-ish header (the one saying > "next is text" or "next is binary") that concerns you? > > > On Wed, Dec 3, 2014 at 9:00 AM, Roberto Peon <grmocg@gmail.com> wrote: > >> Basically one either needs flow controlled headers, or needs a headers >> frame (or equivalent) which doesn't use a compression context, plus a >> dataframe which can signal end-of-message, at which point we have >> everything one could conceivably need for a message based protocol. >> >> -=R >> On Dec 3, 2014 8:17 AM, "Martin Thomson" <martin.thomson@gmail.com> >> wrote: >> >>> On 3 December 2014 at 07:49, Yutaka Hirano <yhirano@google.com> wrote: >>> >> a mechanism (HEADERS would do if it can be flow controlled on the one >>> >> stream) to modify metadata >>> > >>> > Sorry I'm not sure what it means: Can you explain? >>> >>> HEADERS >>> Subsequent-Frames-Will-Be: binary >>> Other-WebSockets-Meta-Information: here >>> DATA... >>> binary frame data >>> HEADERS >>> Subsequent-Frames-Will-Be: text >>> DATA... >>> text frames >>> >>> Roberto wants HEADERS (other than the first) to be flow controlled, >>> but that isn't entirely relevant here. >>> >> >
Received on Thursday, 4 December 2014 03:06:03 UTC