Re: Making Implicit C-E work.

On 30 April 2014 07:54, 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.
>>>
>>>
>> 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.
>
>

Well, it changes a client's ability to request an uncompressed entity.



>
>>
>>
>>> 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.​
>
​
>
​​
Yeah, mandating it. Which I'm not happy about.

​

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

​Indeed.



> 2) We know that software and vendors out there take shortcuts which harm
> performance and have been harming interop.
>

I'm just saying ​this isn't the time or the way to fix it. One battle at a
time. Use TCP better and make headers less bloaty now -- issues that affect
everyone on the web; worry about edge cases like stupid or malicious
proxies later.



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

​Sure, so what does a 1.1->2 proxy do when a 1.1 client requests
Accept-Encoding:identity​ + Cache-Control:no-transform and the 2 server
responds with Content-Encoding:gzip ? That's currently possible, even if
unlikely, and we still have no suggestion at all for what the proxy is
supposed to do about it. Undocumented unlikely edge cases are the worst
kind, no? I think that makes the current draft undeployable for those
gateways, and they're the ones who are going to be doing a lot of the heavy
lifting of getting HTTP/2 out there to the masses.



>
> 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?
>
>
Which problem, exactly? If it's that people are doing a certain thing in
HTTP/1.1, then the simplest solution is: let them keep doing it. No need to
add any words to the spec.​ If some proxy is stripping Accept-Encoding
headers, that's a raw deal for the users behind it, but it doesn't break
the internet. Those users would still see an improvement after switching to
HTTP/2.



> An HTTP2 without C-E based compression will not achieve some of the
> objectives that it would with it.
>
>
It's not without compression, it just doesn't mandate it. What we gain in
return is: not creating paradoxes in the protocol. Arguing pragmatism is
all well and good, but you still haven't fully addressed the gateway issue.
Theoretical holes have ways of becoming real, practical holes, and often
reveal massive security issues when they do so.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/