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


From: Mike Belshe <mike@belshe.com>
Date: Mon, 27 Jan 2014 13:52:46 -0800
Message-ID: <CABaLYCvQ-hJOFRFhOZ0jfP+2z1yDBNQix4fDnyNCeskmh4dnoA@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: httpbis mailing list <ietf-http-wg@w3.org>
My guess is that this is a joke that will be reverted.

On Mon, Jan 27, 2014 at 1:46 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> Did anyone complaining actually read the updated text?
> "6.8 GTFO
> ... General Termination of Future Operations ..."

Amos, you're like the Dad in Modern Family who thinks "WTF" is "Why The

But there are no other frame types which are acronyms like this (except for
PING == "Please Indicate Not Gone").


> Anyhow,
> NIT:
>  The intro wording to that explanation seems to be quite unaligned with
> the intro wording for the other frames and obscures interpretation of the
> acronym. Perhapse the editors should re-write it like so:
>   "A General Termination of Future Operations (GTFO) frame (type=0x7)
> informs the remote peer to stop creating streams on this connection."
> 2) The "future operations" appears to be redundant behind "terminate".
> Perhapse it should just be named GENERAL_TERMINATE.
> BUG #1:
>  I am noticing a discontinuity in the textual description of the frame:
> "the GTFO contains the stream identifier of the last stream which was
> processed on the sending endpoint in this connection. If the receiver of
> the GTFO used streams that are newer than the indicated stream identifier,
> they were not processed by the sender and the receiver may treat the
> streams as though they had never been created at all" ...
> ... "An endpoint MUST treat a GTFO frame with a stream identifier other
> than 0x0 as a connection error ..."
> These appear to be mutually exclusive conditions on the use of stream-ID
> for that frame. If implementations follows the MUST condition there is
> nothing graceful about the closure or usefully done with the stream-ID.
> BUG #2:
>  From a state management perspective it is not clear what the recipient of
> these frames is being informed about. ie what should be done in the case
> where multiple streams are underway when GTFO is sent with a stream-ID.
>  * Should that be the last/highest completed stream-ID? if so, what
> happens to incomplete streams with numerically lower ID?
>  * Should it be the stream-ID before the oldest incomplete stream? if so,
> what happens to all the partially handled and complete streams with
> numerically higher IDs?
>  * Should it be the stream-ID of the last frame processed? if so, what is
> it actually telling the remote endpoint?
> Going by the text interpretation I would expect the frame to have a
> stream-ID of 0x0 and a *payload* containing a *list* of the stream-IDs
> which are currently being processed (or relayed in the case of middleware).
> Such that the frame is marked as flow control and recipient can clearly
> identify fully which streams must be completed and which can be re-tried
> elsewhere.
> Amos
Received on Monday, 27 January 2014 21:53:14 UTC

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