Subject: Transfer-codings, mandatory content-coding support and intermediaries

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Apr 2014 16:52:36 +1000

We've had a wide-ranging discussion of the issues brought about by HTTP/2 dropping the concept of transfer-coding, in conjunction with the imposition of mandatory gzip content-coding support by clients.

At this point, it looks like the folks who have asked for TE support in HTTP/2 are willing to wait on incorporating such a feature into HTTP/2. Since we don't seem to have much consensus on any of the proposals to date, the status quo seems like a good path forward -- although I think we should discuss this in more depth in NYC.

However, discussion has also uncovered some problematic aspects of requiring clients to support GZIP content-encoding in HTTP/2. 

Specifically, we're chartered to enable intermediaries to translate from 1.1 to 2 and back with reasonable fidelity. As has been noted, that's hard to do if a HTTP/1 client doesn't support gzip content-encoding; if the HTTP/2 origin assumes gzip support, the intermediary has to decompress it, and -- importantly -- assign a new entity tag to the response. 

That's pretty clearly a major reduction in functionality, and effectively removes what we used to call semantic transparency from all HTTP1.x->HTTP2 proxies. As discussed, there are other side effects of this approach as well.

I've created <https://github.com/http2/http2-spec/issues/460> to track this issue. I don't think it affects the current implementation draft, but we do need to discuss it before (and likely at) the NYC interim.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: <[email-masked]>
Date: Fri, 18 Apr 2014 08:03:16 +0000

On 18 April 2014 08:52 [email-masked] wrote:
> At this point, it looks like the folks who have asked for TE support in HTTP/2
> are willing to wait on incorporating such a feature into HTTP/2.

We're not willing to wait.

> the status quo seems like a good path forward ...
> we should discuss this in more depth in NYC.

If we're going to discuss this in NYC, then it sounds like a really good reason to include it in the current implementation draft - even if it's marked "AT RISK" - so we have experience upon which we can base our discussion.

The primary concern surrounding transfer codings (whatever the variety) seems to be security vulnerabilities related to intermediaries applying compression without proper context.

To appease those concerns, I suggest the following language (or similar language applied to Matthew's frame-level transfer coding proposal or the single-bit gzip proposal - we also support Matthew's proposal)...

9.4 Transfer Codings

HTTP/2 retains the semantics of Transfer-Encoding with the following additional restrictions and requirements.

Servers MUST NOT use the "chunked" transfer coding.

Intermediaries MUST NOT add transfer coding(s).  Intermediaries MAY remove transfer coding(s) if necessary. Intermediaries MAY remove and re-apply transfer coding(s), but the transfer coding(s) MUST be re-applied in the same order as applied by the origin.  For example, an intermediary might elect to remove a gzip transfer coding for local storage in its cache in order to more easily extract a range of the content. In this case, when serving a range, the intermediary can choose to send the range with no transfer coding or with gzip transfer coding, but not with any other transfer coding(s).

Others have mentioned it is "naiive" to think that intermediaries will keep these rules. Agreed. But it is eqaully "naiive" to think intermediares won't do the same thing with C-E. The only solution, IMO, to combat both problems would be signed headers (signed by the origin) - a benefit in favor of TE/Transfer-Encoding over frame-level codings, but we would be happy with either approach.

> ...
> That's pretty clearly a major reduction in functionality, and effectively removes
> what we used to call semantic transparency from all HTTP1.x->HTTP2 proxies.

+1

There were no objections raised by anybody when Matthew, Roland and I brought up these issues, so there doesn't seem to be a good reason to keep it for this implementation draft.

I still think there needs to be a way to allow servers to compress as much as possible (as brought up by Patrick McManus [1] and others [2]).  Implicit gzip on the transfer layer is the right way to accomplish that and retain "semantic transparency" because a HTTP1.x -> HTTP2 intermediary can remove transfer codings without consequence.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1283.html
[2] https://developers.google.com/speed/articles/use-compression

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 09:38:24 -0700

Losing semantic transparency is not good, definitely.

If we add compression at the Transfer-Encoding layer, I am emphatic
that it will not use Transfer-Encoding.  That simply does not work
with the framing layer and would require further exceptions to the
hop-by-hop header rule (I'm unhappy enough about the TE exception).

Matthew's proposal is closer to acceptable, though I think that it
could (and should) be significantly reduced in complexity.  I think
that we could reasonably mandate the use of gzip on a segment by
segment basis, which should help with the security concerns (and
provide a better excuse for including END_SEGMENT).  Strategic
segmentation could be used to separate content.  No alternative
compression schemes or negotiation - those lead to interoperability
failures.

---

From: <[email-masked]>
Date: Fri, 18 Apr 2014 20:50:19 +0000

Despite my comments below, if all we can agree on for this implementation draft is a single gzip bit ("AT RISK"), I think that's better than nothing so we can have some more experience before the discussion in NYC. - As long as something like Matthew's proposal is still on the table (for /2 or /3).

See my comments in-line below...

On 18 April 2014 18:38 Martin Thomson wrote:
> ... we could reasonably mandate the use of gzip on a segment by
> segmentation could be used to separate content.

The beauty of Matthew's proposal is the independent compression context for each frame. It considerably reduces the implementation complexity with a relatively negligible loss in compression factor (see [1] for our test results).

Consider a client managing 100 simultaneous streams. Depending on the interleaving, the client could potentially need to keep around 100 separate decompression contexts. Doing decompression frame-by-frame allows for the possibility of a simple implementation that uses a single context to decompress each compressed frame as it arrives.

If we go with Matthew's proposal (or similar), I still think the security concerns should be managed with language similar to the following...

>> Intermediaries MUST NOT add transfer coding(s).  Intermediaries MAY remove transfer coding(s) if necessary. Intermediaries MAY remove and re-apply transfer coding(s), but the transfer coding(s) MU…

There's no way to let intermediaries add compression without some complicated scheme that requires the origin to mark every frame as sensitive or not.

I am adamant that intermediaries be allowed to remove compression at the transfer layer or we'll have problems transforming 2 -> 1.x.

I also think intermediaries should be allowed to remove compression and then re-apply it, if desired, for exactly the example case mentioned above which was brought up by Amos (see [2]).

> Matthew's proposal ... could (and should) be significantly reduced in complexity. ...
> No alternative compression schemes or negotiation - those lead to interoperability failures.

To be clear, getting rid of negotation means you don't want Matthew's proposal, you just want a single compression bit.

I agree it adds complexity, but on the other hand it would be a shame to lock in to gzip considering there are already compression schemes better suited to dynamic compression (i.e. better CPU performance) e.g. LZ4 is ~10-20 faster than gzip (see [3]).

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0156.html

[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0115.html

[3] http://code.google.com/p/lz4/

>> If we're going to discuss this in NYC, then it sounds like a really good reason to include it in the current
implementation draft - even if it's marked "AT RISK" - so we have experience upon which we can base our discussion.
>>
>> The primary concern surrounding transfer codings (whatever the variety) seems to be security vulnerabilities related to
intermediaries applying compression without proper context.
>>
>> To appease those concerns, I suggest the following language (or similar language applied to Matthew's frame-level
transfer coding proposal or the single-bit gzip proposal - we also support Matthew's proposal)...
>> Intermediaries MUST NOT add transfer coding(s).  Intermediaries MAY remove transfer coding(s) if necessary.
Intermediaries MAY remove and re-apply transfer coding(s), but the transfer coding(s) MUST be re-applied in the same order
as applied by the origin.  For example, an intermediary might elect to remove a gzip transfer coding for local storage in
its cache in order to more easily extract a range of the content. In this case, when serving a range, the intermediary can
choose to send the range with no transfer coding or with gzip transfer coding, but not with any other transfer coding(s).
>>
>>
>>
>> Others have mentioned it is "naiive" to think that intermediaries will keep these rules. Agreed. But it is eqaully
"naiive" to think intermediares won't do the same thing with C-E. The only solution, IMO, to combat both problems would be
signed headers (signed by the origin) - a benefit in favor of TE/Transfer-Encoding over frame-level codings, but we would
be happy with either approach.
>> There were no objections raised by anybody when Matthew, Roland and I brought up these issues, so there doesn't seem to
be a good reason to keep it for this implementation draft.
>>
>> I still think there needs to be a way to allow servers to compress as much as possible (as brought up by Patrick McManus
[1] and others [2]).  Implicit gzip on the transfer layer is the right way to accomplish that and retain "semantic
transparency" because a HTTP1.x -> HTTP2 intermediary can remove transfer codings without consequence.

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 19 Apr 2014 07:21:17 +1000

> compression schemes or negotiation - those lead to interoperability

The obvious simplification, then, would be to change the setting to "accept
gzip (yes/no)" (or replace the setting with a MUST support), and remove the
encoding field from the Data frame.

This tends back towards the single gzip bit, which is alright, as long as
it is clear that the compression context applies only to that data frame.

---

From: David Morris <[email-masked]>
Date: Fri, 18 Apr 2014 14:33:19 -0700 (PDT)

On Sat, 19 Apr 2014, Matthew Kerwin wrote:

> The obvious simplification, then, would be to change the setting to "accept gzip (yes/no)" (or replace the setting with a MUST support), and remove the encoding field
> from the Data frame.
>
> This tends back towards the single gzip bit, which is alright, as long as it is clear that the compression context applies only to that data frame.

I've missed some of the discussion, but I can't imagine why you would
limit the compression context to a single data frame.

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 19 Apr 2014 07:44:36 +1000

On 19 April 2014 07:33, David Morris <[email-masked]> wrote:

> > The obvious simplification, then, would be to change the setting to
> "accept gzip (yes/no)" (or replace the setting with a MUST support), and
> remove the encoding field
> > from the Data frame.
> >
> > This tends back towards the single gzip bit, which is alright, as long
> as it is clear that the compression context applies only to that data frame.
>

​Almost all of the discussion, apparently. If compression contexts can span
DATA frames, then we open the protocol up to CRIME/BREACH attacks again, or
else add extra complexity to limit it. It was also about limiting device's
state commitment for connections (not maintaining compression contexts).​

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

---

From: Michael Sweet <[email-masked]>
Date: Fri, 18 Apr 2014 17:49:47 -0400

FWIW, *if* the goal is to provide semantic compatibility between 1.1 and 2.0, and if we envision 2.0 -> 1.1 proxies being used, then I don't think that a gzip bit on each DATA frame is the right approach.

A 2.0 proxy talking to a 1.1 server can fairly easily convert a 2.0 request using a gzip bit into a 1.1 request using T-E: gzip (just concatenate the gzip streams from each DATA frame), but the reverse will require the proxy to decompress the T-E: gzip stream from the 1.1 server and then either provide an uncompressed response to the 2.0 client or re-compress each DATA frame.

> This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure…

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: <[email-masked]>
Date: Fri, 18 Apr 2014 21:51:29 +0000

> On Apr 18, 2014, at 23:36, [email-masked] wrote:
> I've missed some of the
> discussion, but I can't
> imagine why you would

You trade a bit of compressibility (not much, see [1]) for a serious reduction in implementation complexity.

---

From: <[email-masked]>
Date: Fri, 18 Apr 2014 22:34:12 +0000

On 18 April 2014 23:49, [email-masked] wrote:
> ... *if* the goal is to provide semantic compatibility between 1.1 and 2.0 ...
> A 2.0 proxy talking to a 1.1 server can fairly easily convert a 2.0 request using a gzip bit

> into a 1.1 request using T-E: gzip (just concatenate the gzip streams from each DATA

> frame), but the reverse will require the proxy to decompress the T-E: gzip stream from the

> 1.1 server and then either provide an uncompressed response to the 2.0 client or

> re-compress each DATA frame.

Or the proxy could simply not declare support (i.e. not send a "TE: gzip" header to the server) and then compress the response frame-by-frame, but that also seems like a waste of bandwidth and an ugly hack.

Which begs the question, why not TE/Transfer-Encoding? It would obviously retain semantic compatibility.

I don't understand the need to eliminate all hop-to-hop headers (mentioned by Martin and others). Specifically, what problems are introduced by having T-E in the headers instead of a flag in the frame?

Also, I haven't seen comments yet as to whether or not text similar to the following would appease the security concerns (regardless of the method; T-E or frame-by-frame) ...

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 19 Apr 2014 09:53:34 +1000

On 19 April 2014 07:21, Matthew Kerwin <[email-masked]> wrote:

> remove the encoding field from the Data frame.
>

​I've created another branch​ in my fork to track potential words for this
approach (<https://github.com/phluid61/http2-spec/compare/445-gzip>).  If
it's generally acceptable to the wg I'll submit a PR.

Note that I essentially reinstituted the ZLIB compression from #46, with
some more words, and a setting.  It would be trivial to change it from
RFC1950 ZLIB to RFC 1952 GZIP if that's what people prefer.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 18:56:17 -0700

I could live with that. A little more protocol machinery to reduce the
potential complexity of implementations.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 19:03:06 -0700

We had a long discussion regarding gzip and deflate that ended with a
conclusion of gzip. I'm not sure that it would be worth re-litigating that
decision.

I prefer the safer default of 0 if this is an optional feature. But
contrary to my earlier message, I am reminded that when it comes to
optional features, we have had experience to suggest that they are not a
good way to get interoperability.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 19 Apr 2014 18:43:54 +1200

On 19/04/2014 10:34 a.m., [email-masked] wrote:
>> ... *if* the goal is to provide semantic compatibility between 1.1
>> and 2.0 ... A 2.0 proxy talking to a 1.1 server can fairly easily
>> convert a 2.0 request using a gzip bit
> 
> Or the proxy could simply not declare support (i.e. not send a "TE:
> gzip" header to the server) and then compress the response
> frame-by-frame, but that also seems like a waste of bandwidth and an
> ugly hack.

On the contrary both of those operations are the two Right Ways' (tm) to
do it. Which one is up to the intermediary admin to select

IIRC we seem to have a consensus that a 2.0<->1.1 gateway can do thing
sthat drop the performance of the 1.1 section provided the 2.0 benefits
overall outweighs it.
 So the option of not advertising compression on the 2.0->1.1 hop (which
is almost the status-quo in 1.1) should be acceptible exchange for the
gains from mandatory compression support in the 2.0 traffic arriving at
the gateway.

And since *use* is not mandatory there is not a requirement on the
gateway to encode traffic going in the 1.1->2.0 direction. Although some
may wish to spend some CPU cycles benefiting from the compression.

> I don't understand the need to eliminate all hop-to-hop headers
> (mentioned by Martin and others). Specifically, what problems are
> introduced by having T-E in the headers instead of a flag in the
> frame?
> 
> Also, I haven't seen comments yet as to whether or not text similar
> to the following would appease the security concerns (regardless of
> the method; T-E or frame-by-frame) ...
> 
>>>> Intermediaries MUST NOT add transfer coding(s).  Intermediaries
>>>> MAY remove transfer coding(s) if necessary. Intermediaries MAY
>>>> remove and re-apply transfer coding(s), but the transfer
>>>> coding(s) MUST be re-applied in the same order as applied by
>>>> the origin.

NP: this is not good.
 Consider a client advertising X, Z encoding supported. Proxy advertises
X, Y, Z. If the origin chose to layer encoding X-over-Y-over-Z it may
have done so because X-over-Z has a vulnerability. Stripping the X and Y
*both* would seem acceptible, since the client is only hoping for X
and/or Z. But re-encoding X-over-Z is tricky.

IMO the intermediary should either relay as-is or just strip away
encodings down to a layer the client has advertised support for.

>>>>  For example, an intermediary might elect to remove
>>>> a gzip transfer coding for local storage in its cache in order
>>>> to more easily extract a range of the content. In this case,
>>>> when serving a range, the intermediary can choose to send the
>>>> range with no transfer coding or with gzip transfer coding, but
>>>> not with any other transfer coding(s).
> 

-1 on this particular wording. You seem to be conflating
transfer-encoding with content-encoding.

In regards to caching:

* Transfer-Encoding is expected to decode on arrival (or at least act
like it has). It must be uncompressed for delivery to the store logics.
  -> The entity being cached is the un-encoded object form.

* Content-Encoding is expected to retain its compression while in the
storage.
  -> The entity being cached is the encoded object form.

The catch in regards to caching per-segment 2.0 compression is retaining
the SEGMENT tagging on byte ranges within the stream payload. But that
is an implementation detail I am sure we caching people can sort out
fairly easily.

My 2c.:

The need for Transfer-Encoding is explicitly about giving intermediaries
flexibility to choose on the transfer of *specific* payloads. A blanket
all-or-nothing MUST/MUST NOT for every possible payload is too absolute
and inflexible to cover every use case properly.
 Given that, the impetus should be on having a signal from the origin
about whether encoding/compression can be added (or not) by the
intermediaries on a particular segment.

Taking this a little further, I wonder if simply extending
Cache-Control:no-transform to mean that not even Transfer-Encoding is
permitted on this stream is sufficient for resolving the security edge
cases. It should then be okay for the spec to allow Transfer-Encoding on
all transformable traffic by default, same as in HTTP/1.1 today
(perhapse with a must-support for gzip etc which are desirable).
 The per-frame compression should in turn reduce the need for adding
no-transform control in the group of segmented transactions which are
non-cacheable with varying security needs (but if in doubt use
no-transform).

Amos

---

From: <[email-masked]>
Date: Sat, 19 Apr 2014 19:21:20 +0000

On 19 April 2014 04:03, Martin Thomson wrote:
> contrary to my earlier message, I am reminded that when it comes to optional features,
> we have had experience to suggest that they are not a good way to get interoperability.
>

> On Apr 18, 2014 4:53 PM, Matthew Kerwin wrote:
>> ... or replace the setting with a MUST support ...

+1

Make it non-optional, particularly if we are considering removing mandatory support for C-E gzip due to the "semantic transparency" problem. I think the origin should always have an option for compression.

---

From: <[email-masked]>
Date: Sat, 19 Apr 2014 19:54:44 +0000

Several of you (e.g. Martin [1]) have repeatedly mentioned security concerns w.r.t. "blanket" compression at the transfer layer without proper context about the data being compressed.

Have you all really changed your minds regarding the security implications? (If so, please share what convinced you otherwise.)

If not, I suggest adding restrictions to Matthew's PR [2] about the use of gzip frame compression.

I suggest something like the following...

Intermediaries MUST NOT add GZIP compression to a DATA frame. Intermediaries MAY remove GZIP compression frome DATA frames if necessary. Intermediaries MAY also remove and re-apply GZIP compression, so long as all compressed data were originally compressed by the origin.

For example, an intermediary might elect to remove GZIP compression for local storage in its cache in order to more easily extract a range from the content. In this case, when serving a range, the intermediary can choose to send the range in DATA frames with no compression or with GZIP compression (or a combination thereof).

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0166.html

[2] https://github.com/phluid61/http2-spec/compare/445-gzip

---

From: Roland Zink <[email-masked]>
Date: Sat, 19 Apr 2014 22:05:35 +0200

> This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure…
+1 on requiring compression support

---

From: Patrick McManus <[email-masked]>
Date: Sat, 19 Apr 2014 18:15:39 -0400

nothing in this thread has really changed the basic design decisions
already in the current drafts
 * hop to hop transfer encodings have never been widely used successfully -
let's get rid of them
 * implicit end to end content encoding improves a known abuse of the
protocol.

Sure, that makes http/2 gateways have to work a little harder with lame
http/1 clients. that's a reasonable price.

i'm in favor of the status quo here (i.e. no TE and implicit CE: gzip). The
alternative seems to be some form of per frame gzip changes at this point
with no implementation experience and a literal trail of tears in recent
non-content-aware compression schemes when mixed with TLS. Let's not do
that :)

-P

On Fri, Apr 18, 2014 at 2:52 AM, Mark Nottingham <[email-masked]> wrote:

> We've had a wide-ranging discussion of the issues brought about by HTTP/2
> dropping the concept of transfer-coding, in conjunction with the imposition
> of mandatory gzip content-coding support by clients.
>
> At this point, it looks like the folks who have asked for TE support in
> HTTP/2 are willing to wait on incorporating such a feature into HTTP/2.
> Since we don't seem to have much consensus on any of the proposals to date,
> the status quo seems like a good path forward -- although I think we should
> discuss this in more depth in NYC.
>
> However, discussion has also uncovered some problematic aspects of
> requiring clients to support GZIP content-encoding in HTTP/2.
>
> Specifically, we're chartered to enable intermediaries to translate from
> 1.1 to 2 and back with reasonable fidelity. As has been noted, that's hard
> to do if a HTTP/1 client doesn't support gzip content-encoding; if the
> HTTP/2 origin assumes gzip support, the intermediary has to decompress it,
> and -- importantly -- assign a new entity tag to the response.
>
> That's pretty clearly a major reduction in functionality, and effectively
> removes what we used to call semantic transparency from all HTTP1.x->HTTP2
> proxies. As discussed, there are other side effects of this approach as
> well.
>
> I've created <https://github.com/http2/http2-spec/issues/460> to track
> this issue. I don't think it affects the current implementation draft, but
> we do need to discuss it before (and likely at) the NYC interim.
>
> Cheers,
>
>
>
>
> --

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 20 Apr 2014 09:06:27 +1000

>  * hop to hop transfer encodings have never been widely used successfully
- let's get rid of them

This is the first time I've seen such a level of simultaneous action from
implementers, combined with the closest thing to a "clean slate" I've ever
seen in http -- especially regarding transport issues. If this isn't the
time to get people on board and collectively do things properly, I don't
know what is.

protocol.

Do you mean compared to hop-by-hop, or to no compression at all? To which
known abuse do you refer?

In either case, I suspect that widely supported *explicit* end to end
encoding would also suffice.

Not reasonable if C-E compression is mandatory. We don't make them work
harder, we put them in a situation where they *cannot* proceed; effectively
fragmenting the web into HTTP2 bits and "lame" bits. Maybe we say "sucks
for them", their fault for being the way they are, but I don't want the
http2 message to be "you can only join in if you're worthy".

>
> i'm in favor of the status quo here (i.e. no TE and implicit CE: gzip).
The alternative seems to be some form of per frame gzip changes at this
point with no implementation experience and a literal trail of tears in
recent non-content-aware compression schemes when mixed with TLS. Let's not
do that :)

Normally I'm happy for status quo, but the current text contains an
oversight. The only real alternative is to remove the "MUST support" for
gzip C-E -- that's the part that breaks the protocol. If anyone is still
desperate for compression then only place we're able to add it is in the
transport/framing layer.

---

From: Nicholas Hurley <[email-masked]>
Date: Sat, 19 Apr 2014 16:43:43 -0700

+1 to everything Patrick has said.

If, however, we end up doing some sort of (ill-advised) hop to hop transfer
encoding, then it should absolutely be (1) optional, and (2) opt-IN (not
opt-out, as Matthew's branch has it)

-- 
Peace,
  -Nick

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 20 Apr 2014 10:00:36 +1000

On 20 Apr 2014, at 8:15 am, Patrick McManus <[email-masked]> wrote:

> nothing in this thread has really changed the basic design decisions already in the current drafts
>  * hop to hop transfer encodings have never been widely used successfully - let's get rid of them

That seems to be a widely-held belief, with a few exceptions. However, I personally think Matthew's most recent proposal is quite reasonable, especially if it flips to being opt-out. While browsers might not use them, API folks could find this quite attractive (as we're hearing from the IAEA people).

Daniel, any thoughts from a curl perspective here -- would you support a "compressed data frame" flag?

>  * implicit end to end content encoding improves a known abuse of the protocol.

Calling it "abuse" is a value judgement. While it's true that we're chartered to improve performance, those performance gains should not come at the cost of interoperability, which is what we're seeing here.

Also, since many have stated an intent to only deploy HTTP/2 over TLS, I wonder how bad this "abuse" will be. 

> Sure, that makes http/2 gateways have to work a little harder with lame http/1 clients. that's a reasonable price.

No, that's not the problem. The problem is that the gateways have to become non-transparent, making it more difficult for clients to interoperate *through* them.

> i'm in favor of the status quo here (i.e. no TE and implicit CE: gzip). The alternative seems to be some form of per frame gzip changes at this point with no implementation experience and a literal trail of tears in recent non-content-aware compression schemes when mixed with TLS. Let's not do that :)

That's a false choice. We need to deal with the interop problems whether or not we introduce hop-by-hop compression.

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 20 Apr 2014 12:50:10 +1000

On 20 April 2014 10:00, Mark Nottingham <[email-masked]> wrote:

>
> ​[snip]
>  I personally think Matthew's most recent proposal is quite reasonable,
> especially if it flips to being opt-out. While browsers might not use them,
> API folks could find this quite attractive (as we're hearing from the IAEA
> people).
>
>
I assume you mean flipping to opt-in. Since you and Martin have both said
you'd prefer it, and since it doesn't make a difference to me, I've
switched the text around in my branch. I think there should probably be
something in the COMPRESSED flag section to describe the error condition,
or at least reference the setting. I've also changed zlib to gzip.​

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 20 Apr 2014 13:43:37 +1000

On 20 Apr 2014, at 12:50 pm, Matthew Kerwin <[email-masked]> wrote:

> ​[snip] I personally think Matthew's most recent proposal is quite reasonable, especially if it flips to being opt-out. While browsers might not use them, API folks could find this quite attractive (as we're hearing from the IAEA people).
> 
> 
> I assume you mean flipping to opt-in.

Yes; typing before coffee.

> Since you and Martin have both said you'd prefer it, and since it doesn't make a difference to me, I've switched the text around in my branch. I think there should probably be something in the COMPRESSED flag section to describe the error condition, or at least reference the setting. I've also changed zlib to gzip.​
> 
> 
> -- 
>   Matthew Kerwin

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sun, 20 Apr 2014 17:51:05 +0900

On Sun, Apr 20, 2014 at 8:43 AM, Nicholas Hurley <[email-masked]>wrote:

> If, however, we end up doing some sort of (ill-advised) hop to hop
> transfer encoding, then it should absolutely be (1) optional, and (2)
> opt-IN (not opt-out, as Matthew's branch has it)
>
>
​+1 to what Nicholas wrote. I'd like to make it optional completely.

Best regards,
Tatsuhiro Tsujikawa

>>> We've had a wide-ranging discussion of the issues brought about by
>>> HTTP/2 dropping the concept of transfer-coding, in conjunction with the
>>> imposition of mandatory gzip content-coding support by clients.
>>>
>>> That's pretty clearly a major reduction in functionality, and
>>> effectively removes what we used to call semantic transparency from all
>>> HTTP1.x->HTTP2 proxies. As discussed, there are other side effects of this
>>> approach as well.
>>>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Apr 2014 11:02:07 +0200

> No, that's not the problem. The problem is that the gateways have to become non-transparent, making it more difficult for clients to interoperate *through* them.

Such as rewriting ETags, right?

This is a hard problem. Apache httpd's compression module doesn't get it 
right. Are we aware of *any* piece of middleware that does get it right?

Note that this also requires rewriting request header (conditionals), 
and would always be limited to what the middleware knows about (so ETags 
in payloads and new conditional header fields will be broken...).

Best regards, Julian

---

From: Roland Zink <[email-masked]>
Date: Sun, 20 Apr 2014 18:21:51 +0200

> successfully - let's get rid of them
True
>  * implicit end to end content encoding improves a known abuse of the 
I see it differently, e.g. mandating C-E casts a known abuse of the 
protocol in concrete
>
> Sure, that makes http/2 gateways have to work a little harder with 
> lame http/1 clients. that's a reasonable price.
>
In a pure http/2 world intermediaries will do the same, e.g. do dynamic 
C-E gzip the same way as they do now.
> i'm in favor of the status quo here (i.e. no TE and implicit CE: 
> gzip). The alternative seems to be some form of per frame gzip changes 
> at this point with no implementation experience and a literal trail of 
> tears in recent non-content-aware compression schemes when mixed with 
> TLS. Let's not do that :)
>
Considering doing C-E and T-E gzip on the whole file the compressed bits 
send over the wire are the same, so when there is a security issue with 
one of it shouldn't it apply to the other as well?

Regards,
Roland

> -P
>
>
>
> On Fri, Apr 18, 2014 at 2:52 AM, Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     HTTP/2 dropping the concept of transfer-coding, in conjunction
>     with the imposition of mandatory gzip content-coding support by
>     clients.
>
>     At this point, it looks like the folks who have asked for TE
>     support in HTTP/2 are willing to wait on incorporating such a
>     feature into HTTP/2. Since we don't seem to have much consensus on
>     any of the proposals to date, the status quo seems like a good
>     path forward -- although I think we should discuss this in more
>     depth in NYC.
>
>     Specifically, we're chartered to enable intermediaries to
>     translate from 1.1 to 2 and back with reasonable fidelity. As has
>     been noted, that's hard to do if a HTTP/1 client doesn't support
>     gzip content-encoding; if the HTTP/2 origin assumes gzip support,
>     the intermediary has to decompress it, and -- importantly --
>     assign a new entity tag to the response.
>
>     effectively removes what we used to call semantic transparency
>     from all HTTP1.x->HTTP2 proxies. As discussed, there are other
>     side effects of this approach as well.
>
>     I've created <https://github.com/http2/http2-spec/issues/460> to
>     track this issue. I don't think it affects the current
>     implementation draft, but we do need to discuss it before (and
>     likely at) the NYC interim.
>
>     Cheers,
>
>
>
>
>     --

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 20 Apr 2014 18:36:37 +0200 (CEST)

> "compressed data frame" flag?

I would expect that feature to be something machine API consumers might like, 
so yes I would imagine that I would work on implementing it.

curl is also one of those clients that has transfer-encoded gzip support for 
HTTP 1.1 so I figure it would match that...

-- 

  / daniel.haxx.se

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Apr 2014 09:57:49 +1000

On 20 Apr 2014, at 7:02 pm, Julian Reschke <[email-masked]> wrote:

> This is a hard problem. Apache httpd's compression module doesn't get it right. Are we aware of *any* piece of middleware that does get it right?
> 
> Note that this also requires rewriting request header (conditionals), and would always be limited to what the middleware knows about (so ETags in payloads and new conditional header fields will be broken…).

… which is one of the reasons I think we need to seriously consider dropping this text.

Regards,

---

From: <[email-masked]>
Date: Mon, 21 Apr 2014 12:10:07 +0000

On 20 April 2014 01:06, Matthew Kerwin wrote (emphasis added):
>> i'm in favor of the status quo here (i.e. no TE and implicit CE: gzip). ...

>
> Normally I'm happy for status quo, but the current text contains an oversight. The only real alternative is to

> remove the "MUST support" for gzip C-E -- that's the part that breaks the protocol. If anyone is still

> desperate for compression then only place we're able to add it is in the transport/framing layer.

Patrick, in an earlier thread regarding removal of implicit C-E gzip, you wrote [1] ...

"CE gzip was made a fixed part of the protocol, in part, because intercepting intermediaries (or antivirus libraries as a subset of that) were explicitly stripping negotiation for it for their own convenience. Making it non negotiable enhances the robustness of the protocol against that which is imo the right trade given the history here and the importance of compression."

In light of the mounting support against implicit C-E gzip, how would you propose to deal with the problem you mentioned above? and the importance of compression?

As Matthew pointed out, if a server wants the ability to always use compression, no matter what, then the only place that will likely be possible is at the transport/framing layer. Other ideas? Or is compression not that important that you would be willing to use it?

I bring it up because making transport/framing gzip optional, means that servers won't always have the option to compress.

+1

+1 to everything Roland said.

+1 to everything Matthew said.

---

From: <[email-masked]>
Date: Mon, 21 Apr 2014 12:22:32 +0000

I'm sorry to respond to my own e-mail (below), but I don't understand why everybody is ignoring the security aspects of transfer/framing layer compression without contextual information (e.g. by intermediaries).

Patrick brought it up yesterday, so obviously he still thinks its an issue.

> ... The alternative seems to be some form of per frame gzip changes at this point with no implementation

> experience and a literal trail of tears in recent non-content-aware compression schemes when mixed with TLS.

Regarding my suggestion below, will somebody please at least respond and tell me why I'm wrong and/or give another suggestion?

> Intermediaries MUST NOT add GZIP compression to a DATA frame. Intermediaries MAY

> remove GZIP compression frome DATA frames if necessary. Intermediaries MAY also

> remove and re-apply GZIP compression, so long as all compressed data were

> originally compressed by the origin.

> For example, an intermediary might elect to remove GZIP compression for local

> storage in its cache in order to more easily extract a range from the content. In

> this case, when serving a range, the intermediary can choose to send the range in

> DATA frames with no compression or with GZIP compression (or a combination

> thereof).

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 21 Apr 2014 23:13:14 +1000

On 21 April 2014 22:22, <[email-masked]> wrote:

>
> Regarding my suggestion below, will somebody please at least respond and
> tell me why I'm wrong and/or give another suggestion?
>
It's too hard to enforce that MUST NOT; it's quite likely to become an RFC
6916-style "MUST NOT (BUT WE KNOW YOU WILL)"​. Or put more politely: if
someone implemented it by mistake, how would anyone ever detect it?

An alternative which I'm starting to imagine might be to use END_SEGMENT to
delineate secret data and potentially-attacker-supplied data; that way we
can ensure that the two sets of data never end up in the same DATA frame /
compression context. That resolves the vulnerability I'm aware of
introduced by compression; I don't know how to protect against
vulnerabilities of which I'm not aware, in anything.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 21 Apr 2014 09:24:41 -0400

On Mon, Apr 21, 2014 at 8:10 AM, <[email-masked]> wrote:

>  how would you propose to deal with the problem you mentioned above? and
> the importance of compression?
>
>
I support keeping the implicit CE gzip and not doing anything regarding TE
or hop-to-hop encodings for reasons discussed previously.

---

From: Albert Lunde <[email-masked]>
Date: Mon, 21 Apr 2014 08:54:53 -0500

> An alternative which I'm starting to imagine might be to use END_SEGMENT
> to delineate secret data and potentially-attacker-supplied data; that
> way we can ensure that the two sets of data never end up in the same
> DATA frame / compression context. That resolves the vulnerability I'm
> aware of introduced by compression; I don't know how to protect against

My impression was that attacks using compression as an oracle to reveal 
secret data in turn are driven by using JavaScript to manipulate requests.

I doubt that most web browser clients have a security model
that can reliably identify "potentially-attacker-supplied data"; too 
much of the content, including JavaScript _is_ 
potentially-attacker-supplied, and there are too many back doors from 
one context to another.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 09:35:18 -0700

On 21 April 2014 06:54, Albert Lunde <[email-masked]> wrote:
> that can reliably identify "potentially-attacker-supplied data"; too much of
> the content, including JavaScript _is_ potentially-attacker-supplied, and
> there are too many back doors from one context to another.

That's not true.  Web browser clients have very robust attribution
models.  We don't necessarily want to use those, because it's a fair
complexity burden.

The real problem here is less with clients, but servers.  The BEAST
demonstrations exploited servers that dynamically compressed content
without regard to the source of the compressed content.

---

From: <[email-masked]>
Date: Mon, 21 Apr 2014 17:58:31 +0000

On 21 April 2014 15:24, [email-masked]<mailto:[email-masked]> wrote:
> I support keeping the implicit CE gzip

Not realistic IMO (given the growing list of problems caused by implicit CE gzip).

> and not doing anything regarding TE or hop-to-hop encodings for reasons discussed previously.

I infer that you think compression is important given your previous comments.  Any other ideas for requiring clients to support compression or are you only pinning your hopes on implicit CE gzip?

---

From: <[email-masked]>
Date: Mon, 21 Apr 2014 18:10:57 +0000

On 21 April 2014 15:13, Matthew Kerwin wrote:
> It's too hard to enforce that MUST NOT; it's quite likely to become an RFC 6916-style "MUST NOT
> (BUT WE KNOW YOU WILL)"​. Or put more politely: if someone implemented it by mistake, how would
> anyone ever detect it?

Thanks for the response.  Do all MUST-level requirements have to be enforceable? (If so, I didn't know that.)

Would it work to replace MUST NOT with SHOULD NOT?  (SHOULD NOT isn't enforceable by definition right?)

At the very least, please add some sort of "security considerations" for transfer/frame layer compression, particularly with respect to intermediaries.

(IMO, the right way to enforce a lot of this would be signing unmodifiable headers etc. by the origin. I guess that will have to wait for HTTP/3 though.)

> An alternative which I'm starting to imagine might be to use END_SEGMENT to delineate secret data and
> potentially-attacker-supplied data; ...

I'm not sure exactly how you would implement that, but I imagine it would get very complicated in a hurry.
Besides, I still don't see how you could enforce any requirements that intermediaries don't add compression.
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 11:30:42 -0700

> Thanks for the response.  Do all MUST-level requirements have to be enforceable? (If so, I didn't know that.)

That's not quite the right question.  We use "MUST" to proscribe
behaviour so that an endpoint does not do things (ultimately, generate
or not generate packets in particular patterns) that might affect a
peer endpoint negatively.  In general, if compliance with the "MUST"
cannot be detected, then there's no point in saying it.
Implementations that detect behaviour that contradicts a "MUST" are
entitled to do whatever they want with the connection, since it's
clear at that point the peer is not talking the protocol they
originally thought.  The recommendation we make is to send an error
message using the original protocol and terminate the connection.

For example, there's no way to tell an implementation with a bad
server implementation of HTTP/2 prioritization from one with a badly
misbehaving back-end.  Thus, we don't use MUST when talking about
prioritization (or at least, we shouldn't be).

So, I think that your answer is "yes".

---

From: <[email-masked]>
Date: Mon, 21 Apr 2014 19:47:35 +0000

On 21 April 2014 20:30 Martin Thomson wrote:
> In general, if compliance with the "MUST" cannot be detected, then there's no point in saying it.
> ...

Thanks for the clarification.

Re-reading RFC 2119 [1], it seems like SHOULD NOT might be appropriate in this circumstance.  But regardless, at a minimum the security considerations of compression without proper context should be explicitly enumerated.

>From RFC 2119 Section 7...
"Document authors should take the time to elaborate the security implications of not following
recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification."

> Intermediaries SHOULD NOT add GZIP compression to a DATA frame. Intermediaries MAY

[1] http://tools.ietf.org/html/rfc2119

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 13:19:42 -0700

On 21 April 2014 12:47,  <[email-masked]> wrote:
> But regardless, at a minimum the security considerations of compression without proper context should be explicitly enumerated.

Can you tell me exactly how this [1] falls short?

[1] http://http2.github.io/http2-spec/#rfc.section.10.6

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 21 Apr 2014 15:34:50 -0700

+1

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 22 Apr 2014 10:22:53 +1000

On 22 April 2014 08:34, William Chan (陈智昌) <[email-masked]> wrote:

>> I support keeping the implicit CE gzip and not doing anything regarding
>> TE or hop-to-hop encodings for reasons discussed previously.
>>
>>
>
​T-E aside (because I think it's clear where I stand on that), ​I'm
strongly against keeping implicit C-E gzip.

Reasons for it:

P1. Lazy intermediaries have no way to strip it from the accept-encoding
headers. True, evil virus scanners might do this, clogging up the tubes for
no good reason; but there are also some legitimate use-cases for stripping
the header, e.g. con #2, below.

P2. Browsers save ~5 bytes in accept-encoding headers. Slightly facetious,
but it is a benefit...

Reasons against it:

C1. It puts no burden whatsoever on origins to send C-E. Lots of clients
already explicitly accept gzip-- which has lead to the pathological case of
intermediaries adding it. Forcing people to accept the encoding will likely
only encourage intermediaries to keep on doing the wrong thing. Naive
non-origin compression is the basis of the all security concerns I've heard
surrounding compression.

C2. It *breaks* the protocol in one edge case, where a HTTP/1.1 request to
a gateway includes Cache-Control:no-transform, and does not include
Accept-Encoding:gzip. We haven't given intermediaries an out, apart from
some sort of ugly 5xx (maybe 502?), and we certainly haven't blessed them
to ignore the no-transform.

​C3. From my ivory tower: this change to a non-transport header does not
belong in HTTP/2. Modifying semantics to "improve​" the way people use the
web is way outside the charter.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 21 Apr 2014 23:59:48 -0700

> without regard to the source of the compressed content.

They exploit compression of user-provided data within a secure channel
that can be observed by the attacker (on the same network).
Not surprisingly, most HTTP use cases are not effected.

Likewise, restricting packet sizes to a small length in order to
prevent fools from HOL blocking their own multiplexed channels
makes some sense, for browser developers.  However, it actively
harms applications of HTTP that are not interested in multiplexing
because they only want to transmit a single large data stream.
[E.g., for SSH, we have "http://www.psc.edu/index.php/hpn-ssh".]

I don't think it makes sense to limit an application-level protocol
to the worst case.

....Roy

---

From: <[email-masked]>
Date: Tue, 22 Apr 2014 07:49:30 +0000

Hi Martin-

On Monday,21 April 2014 22:20, Martin Thomson wrote:
> On 21 April 2014 12:47,  <[email-masked]<mailto:[email-masked]>> wrote:

> [1] http://http2.github.io/http2-spec/#rfc.section.10.6

Section 10.6 "Use of Compression" says "Compression MUST NOT be used if the source of data cannot be reliably determined."  Admittedly, if you read between the lines, this basically says intermediaries should never add compression because they likely know nothing about the data and their source. My suggestion was to state it more explicitly.

For example, in the very next section (10.7 "Use of Padding"), the final statement is...

"Intermediaries SHOULD NOT remove padding, though an intermediary MAY remove padding and add differing amounts if the intent is to improve the protections padding affords."

I was suggesting adding a similar statement, but directly in the section describing the DATA frame gzip flag (i.e. Matthew’s PR), because intermediaries should never add/remove C-E compression IMO.

“Intermediaries SHOULD NOT add gzip compression, though an intermediary MAY remove gzip compression, particularly if disabling compression might mitigate attacks that rely on compression*. Intermediaries MAY also remove and then re-apply gzip compression if necessary, e.g. to extract a range.”

*for example, if an intermediary is forwarding compressed plain text traffic from an origin server to a TLS tunnel

I don’t care that much though so I’m done bringing it up :)

-keith

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Apr 2014 17:52:58 +1000

<https://github.com/http2/http2-spec/issues/460>

Folks,

This isn't a voting exercise. If you want to keep the implicit CE gzip, please address the problems called out in the issue.

Thanks,

On 22 Apr 2014, at 8:34 am, William Chan (陈智昌) <[email-masked]> wrote:

> +1
> 
> 
> On Mon, Apr 21, 2014 at 6:24 AM, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
>  how would you propose to deal with the problem you mentioned above? and the importance of compression?
> 
> 
> I support keeping the implicit CE gzip and not doing anything regarding TE or hop-to-hop encodings for reasons discussed previously.

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 22 Apr 2014 13:26:59 +0200 (CEST)

On Mon, 21 Apr 2014, Roy T. Fielding wrote:

> Likewise, restricting packet sizes to a small length in order to prevent 
> fools from HOL blocking their own multiplexed channels makes some sense, for 
> browser developers.  However, it actively harms applications of HTTP that 
> are not interested in multiplexing because they only want to transmit a 
> single large data stream. [E.g., for SSH, we have 
> "http://www.psc.edu/index.php/hpn-ssh".]

TL;DR: I don't think the SSH lesson tells us that small frame sizes are 
necessarily bad.

The longer version:

I've spent some time implementing SSH based protocols and I've analyzed SCP 
and SFTP performance (within the realms of the libssh2 project).

I think you misrepresent the problem hpn-ssh addresses slightly. It is about 
"SSH buffer sizes", and specifically about the ones used by OpenSSH. It is not 
a problem with SSH (the protocol) packet sizes.

SSH has a stream and flow control concept very similar to http2 so yes, 
clients that want maximum throughput for large contents may find themselves 
wanting to announce a (very) large window to the peer.

The big problem with packet sizes within the SSH family, I would say, is for 
sub protocols such as SFTP which suffers greatly from RTT and forces 
implementations to do crazy "pipelining" attempts to overcome that. But that's 
even more off-topic here!

-- 

  / daniel.haxx.se

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 22 Apr 2014 08:17:00 -0700

On Apr 22, 2014, at 4:26 AM, Daniel Stenberg wrote:

>> Likewise, restricting packet sizes to a small length in order to prevent fools from HOL blocking their own multiplexed channels makes some sense, for browser developers.  However, it actively harms applications of HTTP that are not interested in multiplexing because they only want to transmit a single large data stream. [E.g., for SSH, we have "http://www.psc.edu/index.php/hpn-ssh".]
> 
> TL;DR: I don't think the SSH lesson tells us that small frame sizes are necessarily bad.

Er, no, that wasn't the point -- SSH the protocol was designed for
flexibility of application.  SSH the implementation made some implementation
decisions that assumed certain application characteristics, leading to
poor performance outside those characteristics.  HPN-SSH is an example
of how applications try to push the boundaries of protocols.

If SSH the protocol had required limitations similar to those of the
implementation, everyone would be stuck with those limitations until
the next major version of SSH.  So, making limitations on what the
protocol can do just for the sake of one use case (browsers talking to
a walled garden over a multiplexed TLS session) is a bad idea, unless
the protocol you happen to be working on is TLS+ (not HTTP/2).

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Apr 2014 09:22:52 -0700

On 22 April 2014 00:49,  <[email-masked]> wrote:
> Section 10.6 "Use of Compression" says "Compression MUST NOT be used if the
> source of data cannot be reliably determined."  Admittedly, if you read
> between the lines, this basically says intermediaries should never add
> compression because they likely know nothing about the data and their
> source. My suggestion was to state it more explicitly.

I think that this is sufficient, but I'm happy to add more text:
i.e., Compression can be removed, but not added unless additional
information is available.

---

From: James Cloos <[email-masked]>
Date: Wed, 23 Apr 2014 13:17:33 -0400

There is another good reason to remove the implicit c-e,

AFAICT, all of the browser vendors have refused to do HTTP/2.0 outside
of tls.  As such they will avoid the implicit c-e's declared raison d'
etre anyway.

Any intermediary which can MitM the tls will fubar things no matter what
an rfc specifies.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 23 Apr 2014 10:29:40 -0700

> of tls.  As such they will avoid the implicit c-e's declared raison d'

This is factually incorrect, because Microsoft has declared that WinInet
(and thus IE) plan to support HTTP/2 in cleartext via HTTP Upgrade.

---

From: James Cloos <[email-masked]>
Date: Wed, 23 Apr 2014 14:33:02 -0400

>>>>> "WC" == William Chan (陈智昌) <[email-masked]> writes:

JC>> AFAICT, all of the browser vendors have refused to do HTTP/2.0
JC>> outside of tls.

WC> Microsoft has declared that WinInet (and thus IE) plan to support
WC> HTTP/2 in cleartext via HTTP Upgrade.

Thanks; it is good to know that at least someone has commited to
support http upgrade.  I'd prefer all to do so, but thought that
battle lost.

Forcing undeclared compression, though, remains wrong.

-JimC