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

Re: Transfer-codings, mandatory content-coding support and intermediaries

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 22 Apr 2014 08:17:00 -0700
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <6BA31F25-8B02-463D-8345-4A473D6A81B7@gbiv.com>
To: Daniel Stenberg <daniel@haxx.se>
On Apr 22, 2014, at 4:26 AM, Daniel Stenberg wrote:

> On Mon, 21 Apr 2014, Roy T. Fielding wrote:
>> Likewise, restricting packet sizes to a small length in order to prevent fools from HOL blocking their own multiplexed channels makes some sense, for browser developers.  However, it actively harms applications of HTTP that are not interested in multiplexing because they only want to transmit a single large data stream. [E.g., for SSH, we have "http://www.psc.edu/index.php/hpn-ssh".]
> TL;DR: I don't think the SSH lesson tells us that small frame sizes are necessarily bad.

Er, no, that wasn't the point -- SSH the protocol was designed for
flexibility of application.  SSH the implementation made some implementation
decisions that assumed certain application characteristics, leading to
poor performance outside those characteristics.  HPN-SSH is an example
of how applications try to push the boundaries of protocols.

If SSH the protocol had required limitations similar to those of the
implementation, everyone would be stuck with those limitations until
the next major version of SSH.  So, making limitations on what the
protocol can do just for the sake of one use case (browsers talking to
a walled garden over a multiplexed TLS session) is a bad idea, unless
the protocol you happen to be working on is TLS+ (not HTTP/2).

Received on Tuesday, 22 April 2014 15:17:26 UTC

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