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

Re: #445: Transfer-codings

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Tue, 15 Apr 2014 02:51:45 -0600
To: <K.Morgan@iaea.org>
Cc: <msweet@apple.com>, <martin.thomson@gmail.com>, <matthew@kerwin.net.au>, <mnot@mnot.net>, <squid3@treenet.co.nz>, <ilari.liusvaara@elisanet.fi>, <nilsson@opera.com>, <ietf-http-wg@w3.org>, <fielding@gbiv.com>, <derhoermi@gmx.net>, <roland@zinks.de>, <C.Brunhuber@iaea.org>, <jasnell@gmail.com>, <f.kayser@free.fr>
Message-Id: <20140415025145.45573d3012de8473b468abcc@bisonsystems.net>
<K.Morgan@iaea.org> wrote:
> In response to both of you, I am either totally missing something or
> these security concerns related to an intermediary adding compression
> without contextual information are dubious.

+1 because these security concerns...

>  2) In the case of plain-text communication it doesn't matter if the
> intermediary adds or removes a transfer encoding.

...fail to universally apply.

> I get why the other Connection hop-by-hop headers don't make sense,
> but why are transfer-encoding headers such a bad idea? We gave a list
> of 5+ benefits of using TE/Transfer-Encoding.

The response to which seemed to be based on opinion rather than
computer science. Maybe because my take on this whole issue is it's
based on the same resource-representation debate I thought had been
settled. If resources have representations, then it's bad protocol
design for the C-E header to conditionally serve as transfer- or
content- encoding in a fashion that's opaque to intermediaries, thus
requiring them to be authoritative. Or as Roy said, "HTTP/2 should focus
on making features self-descriptive."

Received on Tuesday, 15 April 2014 08:52:13 UTC

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