W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: disabling header compression

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 12 Dec 2013 15:12:51 -0800
Message-ID: <CAP+FsNfKe6j4Bgut2b0aZ_0wN=vO+7WS=Om9sEStQZuq=p2YGQ@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Dec 12, 2013 at 2:47 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> On 13 December 2013 08:27, Roberto Peon <grmocg@gmail.com> wrote:
>> Protocol negotiation is extremely useful.
>> You can happily translate any time I say "ALPN" to mean "protocol
>> negotiation using the registry used for ALPN"
> Are you proposing a protocol negotiation phase for non-TLS HTTP?  Would
> this occur at a lower level (or earlier, like DNS), or inside HTTP itself,
> or in a new intermediate level?  How would it integrate with a HTTP1->2
> upgrade mechanism?

ALPN, DNS, alt-svc, whatever. Upgrade is particularly clunky, and so I'd
prefer other things, but I wouldn't block someone standardizing it. I'd
just not implement it.

>> Don't worry so much :)
> I had the same reaction as Amos, just not the brass to voice it.  If any
> negotiation that happens in ALPN affects the semantics of the HTTP session,
> then there really should be a pathway to achieve it without requiring
> support for ( that particular ALPN protocol token | ALPN in general | TLS
> ).  It seems a bit ripe saying: you can negotiate leaving out the
> complexity of supporting compression, but only if you add in the complexity
> of supporting TLS+ALPN.

I'm not opposed to any particular mechanism so long as at least one
mechanism exists which is lowest-reasonable-possible-latency and is robust
in the face of the problems the internet throws at us.

Be careful about assertions about complexity in this area: the 'easy to
describe' or 'cheap' solutions are not the same as the 'reliably
deployable' solutions, and the set of each changes depending on the
use-case, clients, etc.
Received on Thursday, 12 December 2013 23:13:19 UTC

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