Re: Making Implicit C-E work.

It is more a question of how many intermediaries strip off a-e: gzip, and
how many servers/clients simply assume that it must be there anyway
(causing potential interop issues) because the latency problem (caused by
these intermediaries) was large enough that it mattered.

-=R


On Tue, Apr 29, 2014 at 3:45 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> 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
>