Re: disabling header compression

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.
-=R