Subject: Fwd: New Version Notification for draft-kerwin-http2-encoded-data-01.txt

From: Matthew Kerwin <[email-masked]>
Date: Tue, 22 Jul 2014 10:00:27 +1000

For those interested in such things:

---------- Forwarded message ----------
From: <[email-masked]>
Date: 22 July 2014 09:46

A new version of I-D, draft-kerwin-http2-encoded-data-01.txt
has been successfully submitted by Matthew Kerwin and posted to the
IETF repository.

Name:           draft-kerwin-http2-encoded-data
Revision:       01
Title:          HTTP/2 Encoded Data
Document date:  2014-07-22
Group:          Individual Submission
Pages:          9
URL:
http://www.ietf.org/internet-drafts/draft-kerwin-http2-encoded-data-01.txt
Status:
https://datatracker.ietf.org/doc/draft-kerwin-http2-encoded-data/
Htmlized:
http://tools.ietf.org/html/draft-kerwin-http2-encoded-data-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-kerwin-http2-encoded-data-01

Abstract:
   This document introduces new frame types for transporting encoded
   data in HTTP/2, and an associated error code.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 22 Jul 2014 06:55:47 +0000

In message <CACweHNDQ-rVJW6_uq=[email-masked]>

>http://www.ietf.org/internet-drafts/draft-kerwin-http2-encoded-data-01.txt

So the hacks to cover up deficiencies in the HTTP/2 draft start
already before its even in Last Call ?

Sigh...

Poul-Henning

PS: Compress(1) format ?  In 2014 ?  Really ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Jul 2014 08:48:15 +1000

> already before its even in Last Call ?
I don't know, I'd say it's a testament to the​ extensibility model that it
allows us to produce a lean, functional, interoperable protocol without
overly restricting the internet community's ability to build up on it etc.
etc. (Although end-to-end extensions would be nice.)

Also, there's an "official" precedent:
https://github.com/httpwg/http-extensions/

> PS: Compress(1) format ?  In 2014 ?  Really ?
It's pretty much straight up copy-pasta from
http://tools.ietf.org/html/rfc7230#section-4.2  To be honest I don't care
too much what the initial/eventual set of codings​ is, as long as it's
workable (i.e. at least gzip). My goal was to provide the framework for
people to use whatever codings they prefer. People have requested things
like LZ4 and LZMA, but I don't even know how to reference those since they
don't even have a written specification (just organic reference
implementations).

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 23 Jul 2014 09:14:41 +1000

Matthew,

why are the compression contexts frame only?    Doesn't that make this
extension very vulnerable to fragmentation, specially if we drop
END_SEGMENT as we have done.

Surely there is no harm in having a compression context that is per stream?

If there is a desire to have per frame contexts, can't that be done with
different types rather than saying that no type can have a stream context?

Note that I would like to see transport layer compression because it is
currently a nightmare to implement application layer compression - getting
all the etag, vary headers right is more complex than you'd think,
specially when mixed in with some silly aspects of the servlet API (write
this.... no opps don't)  plus most containers struggle with
applications/content-types that set content-encoding themselves.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Jul 2014 10:26:35 +1000

On 23 July 2014 09:14, Greg Wilkins <[email-masked]> wrote:

> ​
> ​
> ​
> ​
The two main reasons were CRIME/BREACH attacks, and to limit the state
commitment, particularly when transport-level compression was part of the
main spec. I'm trying to dig up a reference to the conversation that lead
to it; here's one cherry I've picked from the archives, which might be a
starting point back from which to work:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0297.html Three
months is such a long time ago, on the internet. :\

Incidentally, END_SEGMENT had potential to enforce useful fragmentation --
i.e. avoiding a CRIME/BREACH attack by separating secret and
attacker-controlled data with an end-to-end barrier -- if the END_SEGMENT
mechanism was exposed to the origin application.

> different types rather than saying that no type can have a stream context?
​It could be, I'm totally up for discussion on it. If the WG wants to adopt
the draft, or just host the discussion on it, I'm cool with that too.
Probably not when we're focusing pretty hard on getting consensus and
closing out issues in the main spec, though.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 23 Jul 2014 16:51:15 +1200

> mechanism was exposed to the origin application.

Fragmentation is not a problem. There are two obvious options from using
a new extension frame type; either 1) define the frame as
non-fragmentable, or 2) containing an END_SEGMENT flag.

Amos

---

From: Roberto Peon <[email-masked]>
Date: Tue, 22 Jul 2014 22:56:38 -0700

Actually, it is an issue, so long as there is no ordering requirement on
extension frames (as we'd have had with END_SEGMENT).

We've not imposed (actually removed) such restrictions on proxies, and so
we may find that there is no way to do it in the future. That would be a
sad day.
-=R

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 23 Jul 2014 18:35:19 +1200

> we may find that there is no way to do it in the future. That would be a

Reference please. I see no mention of proxies being allowed to re-order
any frame type (even control frames) *within* a stream in h2-13.

Amos

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Jul 2014 17:30:05 +1000

> we may find that there is no way to do it in the future. That would be a

Not entirely sure I follow. Extension frames are support-or-discard,
yeah? So what proxy is going to understand the frames well enough to
fragment them, but not enough to realise reordering is bad?

I do see the earlier point about fragemntation, though. Maybe it would
be better to include a "do not coalesce across this boundary" marker
that's more than just the frame boundary.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 Jul 2014 00:34:59 -0700

Just look up the arguments for/against end_segment.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 Jul 2014 00:38:15 -0700

That is what the END_SEGMENT flag *was*, except without the overhead. Ah
well.

Unless the extensions are deployed along with the first versions of HTTP2,
it seems unlikely, given a requirement all intermediaries to understand a
new extension, that an extension will survive transit through any generic
intermediary. Intermediaries (that aren't controlled by the origin server
or client) almost always upgrade more slowly than everything else.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Jul 2014 18:09:20 +1000

> That is what the END_SEGMENT flag *was*, except without the overhead. Ah

Indeed. I'd even mentioned it as a potentially useful feature for
preventing BREACH back in the "compressed data" discussions. I've come
to realise, though, that flags aren't global; not all frames with
FLAGS&0x8 necessarily have padding (or whatever 0x8 is), and certainly
FLAGS&0x1 depends entirely on the frame type to know what it means; so
an END_SEGMENT on data/continuation doesn't imply anything at all
about the same flag being set on an extension frame. Thus, I didn't
and still don't have a problem with END_SEGMENT being removed from the
core frame types, in so far as this extension is concerned.

> or client) almost always upgrade more slowly than everything else.

Not just unlikely - disallowed, if it uses new frame types. This is a
known risk. In this case the people I've heard most support from are
those doing closed-network non-browser API stuff, and it'll probably
be the same for any other extensions. That's a result of there not
being a general end-to-end extension model, though, not just missing
END_SEGMENT.