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

Re: Fwd: New Version Notification for draft-chan-http2-stream-dependencies-00.txt

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Mon, 13 Jan 2014 13:57:10 -0800
Message-ID: <CAA4WUYgyap8PzcPh=SnN2NeHyKvBJfmK4p6AJtpEXO9_7jVMPQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hey Amos, thanks for taking a look!

Sorry for the use of both FIN_ACK and END_STREAM_ACK. The original
document used FIN_ACK, but we renamed to be consistent with the
changing of SPDY FIN flags to HTTP/2 END_STREAM flags. I will rename
the FIN_ACK in a future update to this document.

On Mon, Jan 6, 2014 at 1:55 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> Taking a brief look through this it does look like a better form of
> prioritization than before.
> Two things and out to me:
> * PUSH streams can be depended on by non-PUSH streams and vice versa.
> Possibly leading to a messy situation when an intermediary rejects the
> PUSH'ed resource(s).

I don't know if there's anything special here for push that wouldn't
be addressed generally by how one handles the RST_STREAM case.

> * what happens to the dependencies if a depended-on stream gets RST instead
> of FIN_ACK ?
> Particularly relevant for the PUSH case above, but it can also happen
> anytime.

I think RST_STREAM should be treated similarly to END_STREAM_ACK.
Originally, there was a dependency list. Now, a node has been removed
from that linked list. Either the policy is to automatically
re-connect the list, or the broken list becomes a new list. And
explicit policy can be signaled via PRIORITY frames.

> Security considerations would need to mention the possibility:
> * that an intermediary drops the FIN_ACK frames (or never sends them).
>  It would seem prudent to simply make
>   a) the recipient ignore any priority information if the depended-on stream
> has already completed from its viewpoint, and
>   b) the sender not indicate dependencies on streams already finished
> sending.

I'm not sure if this is a security consideration, but I think it's
correct policy. END_STREAM_ACK is intended to eliminate races here.
Before its receipt, you can always receive references to a depended-on
stream, even if it in the CLOSED state. So its location in the
dependency list is still important and can't be ignored. After receipt
of an END_STREAM_ACK, any future references to that stream are

> * that a naive server can consume processing capacity on the client simply
> by forcing rearrangements of the dependency state data.
>  Some measure of protection is made to prevent multiple updates in one
> PRIORITY frame, but consecutive PRIORITY frames with repeating updates is
> not handled.
>  Transaction preempt may involve significant memory context shifts if the
> client is an intermediary. Too-frequent re-prioritization from the server
> can trigger this overhead. Same can happen from multiplexing, but at least
> some data transfer occurs each frame to offset the inefficiency.

I agree this is a general DoS consideration. As with many other
control frames, the server has to be cognizant of abuse. I think
http://http2.github.io/http2-spec/#rfc.section.10.5 already handles
this, and even already mentions PRIORITY frames.

> Amos
Received on Monday, 13 January 2014 21:57:40 UTC

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