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 Wednesday, 3 December 2014 17:18:52 UTC