Re: Making Implicit C-E work.

On 30/04/2014 10:46 a.m., Matthew Kerwin wrote:
> On 30 April 2014 07:54, Roberto Peon wrote:
> 
>>
>>
>> On Tue, Apr 29, 2014 at 2:45 PM, Matthew Kerwin wrote:
>>
>>> On 30 April 2014 07:33, Roberto Peon 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.
> 

Ahmen.


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

Like those proxies today stripping Accept-Encoding:gzip in order to get
a fully working identity object from the server. In HTTP/2 will very
likely become proxies decompressing on the fly corrupting unknown
amounts of encoding-specific entity header values in the process. If
they dare to try and do the "right" thing by re-compressing it just
makes the new problems worse and less detectable.

So, well, uhm.

Amos

Received on Tuesday, 29 April 2014 23:12:55 UTC