Re: Making Implicit C-E work.

On Tue, Apr 29, 2014 at 4:54 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>
>
> 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.

What percentage of clients do not send "Accept-Encoding: gzip"?

> 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

Received on Tuesday, 29 April 2014 22:45:55 UTC