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

RE: Zero weight for 100 CONTINUE, instead of flow control

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Wed, 2 Apr 2014 20:52:20 +0000
To: David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1d0fcaf2821e409c81f7b309d4e78f9a@BY2PR03MB091.namprd03.prod.outlook.com>
I get the zero-weighted bulk download or video stream, where the client is basically saying that anything else it requests over the connection is more important.

That feels like an odd semantic, though -- the weight of the group implies the client's suggestion to the server on how to prioritize resources.  Overloading it to also, in this instance, reflect the client's wish to know the server's suggestion for how *it* should allocate resources seems a little odd.

Unless we're, in general, supporting that the server can send PRIORITY frames to the client to suggest how the client prioritize its uploads?  I hope not, but maybe I missed that discussion.

-----Original Message-----
From: David Krauss [mailto:potswa@gmail.com] 
Sent: Tuesday, April 1, 2014 12:19 PM
To: HTTP Working Group
Subject: Zero weight for 100 CONTINUE, instead of flow control


>> #436 Enable weight of 0.
>> 
>> Not a lot of feedback here.  Potentially disruptive.
> 
> ... and unless we see discussion on the list very soon, it's not going to make it into this implementation draft.

Oh, I didn't know of the issue, but I was just going to ask about this!

It's a better replacement for 100 CONTINUE than hacking flow control. (See my previous message, "Flow control protocol redundancy.")

Sending a POST with a weight of 0 may notify a server that the sender is unsure whether to proceed. This matches the client-initiated semantic of waiting for CONTINUE.

The disruption can be quite minimal, because a zero-weight condition need not be persistent. Say that an endpoint receiving a zero weight must respond with either a PRIORITY or a RST_STREAM.

Unlike CONTINUE, this does not contort the protocol and rely on specific header processing. Default behavior to always resume the stream (for servers) or discontinue it (for clients) is reasonable for any ignorant application-level software.

I really don't like the idea of using flow control to force the other end to stop. It does not offer appropriate guarantees, it relies on default settings, and it's a violation of network layering principles. Just as CONTINUE is too high-level for what it's supposed to do, flow control is too low-level.
Received on Wednesday, 2 April 2014 20:52:50 UTC

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