Re: Making Implicit C-E work.

On Tue, Apr 29, 2014 at 2:45 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> On 30 April 2014 07:33, Roberto Peon <grmocg@gmail.com> wrote:
>
>> For better or worse, C-E is what is deployed today. Many of my customers
>> will not be writing custom servers, and as such to be deployable, we need
>> solutions that will work with what is out there.
>> Otherwise, the feature is effectively only of theoretical use for the
>> majority of customers.
>>
>>
> ​Sorry, my 7 year old bumped my phone before and sent my message before I
> was finished writing it.
>

The age of mobile has its disadvantages :)


>
> Yes, C-E is what we have, but that's no reason to promote it to a MUST
> support, and even less of a reason to promote it to a MUST support and
> ​have no way to opt out. Some people use C-E as a hack, some other people
> disable the C-E as a hack; whose hack is the worse? You've made your call
> there, but we don't all have to agree.
>
> There is no valid justification for modifying HTTP semantics, and
> dictating how people use entities, in HTTP/2.
>

The proposal doesn't modify HTTP semantics, but preserves them while
offering a needed base capability assurance.


>
>
>
>> I don't dispute that one could use T-E over HTTP/2 for this, assuming
>> that it was end-to-end (which, unfortunately, it will not be for quite some
>> time).
>>
>>
> ​​Beside the point. I'm happy for people to use (and abuse) C-E. I'm just
> not happy for us to promote or mandate it in the spec.
>

As I described it, its use by the originator of an entity is not mandated,
instead behaviors are mandated of recipients when it IS used.
In any case, there are some observations here:
1) We know that compressing things is a huge win and should be done when
security matters don't intrude.
2) We know that software and vendors out there take shortcuts which harm
performance and have been harming interop.
3) We must continue to consider deployability and not just theoretical
usefulness-- the deployability of the protocol is the reason we've gotten
to where we are, and it doesn't make sense to stop thinking about it.

I have a real honest-to-goodness pragmatic deployment problem (myriad
pre-existing servers/clients whose deployment I do not and cannot control)
here that I cannot wish away, and this is a solution.
Can you propose another solution to dealing with this problem which solves
the problem?

An HTTP2 without C-E based compression will not achieve some of the
objectives that it would with it.

-=R