- 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>
<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." -Eric
Received on Tuesday, 15 April 2014 08:52:13 UTC