- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 07 Jan 2014 10:55:34 +1300
- To: ietf-http-wg@w3.org
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). * 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. 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. * 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. Amos
Received on Monday, 6 January 2014 21:56:00 UTC