Subject: http/2 & hpack protocol review

From: <[email-masked]>
Date: Mon, 5 May 2014 12:47:17 +0000

Below is a review of HTTP/2 and HPACK that I received on a private mailing list.  With permission of the author, I am forwarding it to the WG.  I am interested to know what you guys think of the author's suggestions.  -keith

...

HTTP2 and the Internet of Things

Someone recently pointed me to the HTTP2 specification, specifically draft- ietf-httpbis-http2-12.  My first reaction after a quick scan through it was "let me guess, this was driven entirely by browser vendors and large hosting providers".  HTTP2 adds, and changes, a large number of things that have been causing problems for web hosters and browser users, but seems to completely ignore the Internet of things.

By Internet of things I don't mean the buzzword, but the staggering number of devices that use HTTP as a universal substrate for getting data from A to B.

No-one knows how many things are out there, but it's likely to be far, far higher than the number of browser users and web hosting providers (depending on who you ask and what source you use, the figure seems to be around 10-20 billion devices, so it's also significantly larger than the number of people on the planet).

These devices not only don't need stream multiplexing, flow control, prioritisation, unsolicited pushing of messages, Huffman-encoding of headers, and full orchestration and five part harmony, but don't have the resources to implement any of it.  Alternatively, if they do try and implement all of the complexity introduced by HTTP 2, they'll invariably do the absolute minimum required to allow whatever browser the developers are using for testing to connect, and no more, since the developers' goal is to create a functioning Internet-of-things device and not a Google-scale web service.

In fact it's going to be impossible to create something on the level proposed by the HTTP 2 draft since we're talking about devices running on the likes of Cortex M3s, PICs, MSP430s, and ATmegas, which neither need, nor have the resources to implement, most of what's in the HTTP 2 draft.  The only thing that these devices need, and can support, is a substrate for moving a blob of data from A to B.  While something like this is indeed buried in HTTP 2 under layers and layers and layers and layers of complexity, screaming to get out, there doesn't seem to be any way to easily use it as such.

So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users.  The latter should have (or more accurately should *not*

have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others.

Now some of this can be faked (e.g. by setting SETTINGS_HEADER_TABLE_SIZE = 0, SETTINGS_ENABLE_PUSH = 0, SETTINGS_MAX_CONCURRENT_STREAMS = 1, SETTINGS_INITIAL_WINDOW_SIZE = 2^31-1, SETTINGS_COMPRESS_DATA = 0), but a lot of it can't, and in any case it shouldn't be necessary to change a whole pile of parameters just to get a basic HTTP service.

What would be needed for the Internet-of-things profile is:

* A single stream, identifier = 1.  HTTP 2 reserves stream 0 for control

  information which is why stream 1 is used, but for this profile it's assumed

  that, functionally, stream 1 == stream 0, so a stream error or explicit

  close (HEADERS flag END_STREAM or RST_STREAM frame) will close all streams.

* The only allowed frames are HEADERS and DATA, and specifically a single

  HEADERS frame followed by one or more DATA frames, with no trailer frames.

  There are no special-case frames like PING (man, this is reinventing IP over

  HTTP), PUSH_PROMISE, WINDOW_UPDATE (now it's reinventing TCP over HTTP),

  PRIORITY (to this end, the PRIORITY flag in a HEADER should always be

  clear), GOAWAY, CONTINUATION (to this end, the END_HEADERS flag in a HEADER

  should always be set), ALTSVC, BLOCKED, or KITCHENSINK.

* No requirement to support Gzip.

* No header compression apart from the use of indexing (the terminology is

  confusing here, section 4.3.1 calls the use of an index "indexing", sections

  4.3.2 and 4.3.3 call the same use of an index "without indexing", I'm going

  to assume that if an index field is present then it's called "indexed" even

  if the text says the index is "without indexing").

  In other words name:value pairs are always sent in one of three forms:

  - An index into the static table (section 4.2).

  - An index into the static table with attached value (section 4.3.2, literal

    header without indexing, indexed name).

  - The "new name" format if no appropriate table entry exists (section 4.3.2,

               literal header without indexing, new name).

               (As an aside, what's the difference between "Literal Header Field without

               Indexing", described as "A literal header field without indexing causes

               the emission of a header field without altering the header table", and

               "Literal Header Field never Indexed", described as "A literal header field

               never indexed causes the emission of a header field without altering the

               header table"?).

  Any data is sent as octets rather than Huffman encoding, i.e. the 'H' flag

  is always 0.

  (Good grief, the spec for compression is almost as long as the spec for the

  rest of HTTP 2.  Apart from the unworkable complexity on limited devices and

  the fact that it looks like a -00 draft (confusion over what "indexing"

  means, duplication of 4.3.2 in 4.3.3), we're going to be patching vulns in

  implementations of this for the next twenty years).

This takes the enormous implementation complexity of HTTP 2 and profiles it for the Internet of things, allowing for the existing widespread use of HTTP- as-a-substrate, which is everything that's needed, and indeed possible, for vast numbers of devices.

As an aside, how much of what's in the HTTP 2 draft is based on empirical data?  I know that the design of HTTP 1.1 was based on a large number of conference papers and other publications spread over many years that looked at HTTP issues and evaluated performance, but it's not so clear that HTTP 2 has had the same amount of evaluation.  In particular it's implementing stacked TCP, which is never a good idea (see "Why TCP Over TCP Is A Bad Idea", http://sites.inka.de/~W1011/devel/tcp-tcp.html, or the discussion of the "SSH Channel Handbrake" starting at http://www.ietf.org/mail-archive/web/tls/current/msg03363.html), and then adding even more complexity like prioritisation and dependencies and weighting and reprioritisation.  Are the things in HTTP 2 based on any hard data - and by this I mean something more than just 'we measured SPDY on Google's servers and it was better' - or are they, if you'll excuse the expression, just a bunch of Google engineers hacking around?

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: Yoav Nir <[email-masked]>
Date: Mon, 5 May 2014 17:50:52 +0300

Hi, Keith.

I agree with the author that the HTTP/2 draft was driven by the needs of browser vendors and large hosting providers. It is not an ideal protocol for passing small blobs of data from A to B, but then neither is HTTP/1.1.

I mostly agree with the list of things that the devices don’t need, except for the unsolicited pushing of messages. That seems useful for many of the use cases I’ve heard about for the IoT, and in fact is one of the features of CoAP.

I don’t believe that HTTP/2 would become an optimal protocol for the needs of the devices even with the profile. At best it will be barely acceptable, much like HTTP/1.  This is by no means unique. Neither version of HTTP is ideal for downloading 1.5GB operating system updates either, but they’re both good enough that we don’t look for more appropriate protocols. 

I don’t know much about the Internet of Things and their requirements. But I don’t think it’s a good idea to have all data transfer on the Internet happen over the same 5-th layer protocol. The IETF has make CoAP for the use of such devices. Maybe it is appropriate, maybe it is not. And HTTP is certainly easy to deploy because there’s an HTTP library everywhere. But making HTTP fit everybody’s purpose would make it more complex, not less, because all endpoints would have to support the new profile (otherwise we get interop failures).

I guess what I think is that HTTP/2 should be optimized for “the web”. Other use cases should either settle for the not-quite-optimal HTTP/2 (like the OS update download) or use a more appropriate protocol, which could be HTTP/1.x or something else.

Yoav

On May 5, 2014, at 3:47 PM, [email-masked] wrote:

> Below is a review of HTTP/2 and HPACK that I received on a private mailing list.  With permission of the author, I am forwarding it to the WG.  I am interested to know what you guys think of the author’s suggestions.  -keith
>  
> ...
>  
> As an aside, how much of what's in the HTTP 2 draft is based on empirical data?  I know that the design of HTTP 1.1 was based on a large number of conference papers and other publications spread over many years that looked at HTTP issues and evaluated performance, but it's not so clear that HTTP 2 has had the same amount of evaluation.  In particular it's implementing stacked TCP, which is never a good idea (see "Why TCP Over TCP Is A Bad Idea",http://sites.inka.de/~W1011/devel/tcp-tcp.html, or the discussion of the "SSH Channel Handbrake" starting athttp://www.ietf.org/mail-archive/web/tls/current/msg03363.html), and then adding even more complexity like prioritisation and dependencies and weighting and reprioritisation.  Are the things in HTTP 2 based on any hard data - and by this I mean something more than just 'we measured SPDY on Google's servers and it was better' - or are they, if you'll excuse the expression, just a bunch of Google engineers hacking around?
>  
>

---

From: James M Snell <[email-masked]>
Date: Mon, 5 May 2014 08:26:37 -0700

First and foremost, it needs to be recognized that HTTP/2 has been
designed from the start to primarily meet the needs of a very specific
grouping of high volume web properties and browser implementations.
There is very little evidence that ubiquitous use of the protocol is
even a secondary consideration -- in fact, the "they can just keep
using HTTP/1.1" mantra has been repeated quite often throughout many
of the discussions here on this, usually as a way of brushing aside
many of the concerns that have been raised. So be it. It's clear at
this point that HTTP/2 is on a specific fixed path forward and that,
for the kinds of use cases required by IoT, alternatives will need to
be pursued.

FWIW, I am strongly -1 on the use of hpack in http/2. I believe that
there are (and have proposed/argued for) much less complicated
alternatives.

- James

On Mon, May 5, 2014 at 5:47 AM,  <[email-masked]> wrote:
> Below is a review of HTTP/2 and HPACK that I received on a private mailing
> list.  With permission of the author, I am forwarding it to the WG.  I am
> interested to know what you guys think of the author’s suggestions.  -keith
>
>
>
> ...
>
>
>
> Someone recently pointed me to the HTTP2 specification, specifically draft-
> ietf-httpbis-http2-12.  My first reaction after a quick scan through it was
> "let me guess, this was driven entirely by browser vendors and large hosting
> providers".  HTTP2 adds, and changes, a large number of things that have
> been causing problems for web hosters and browser users, but seems to
> completely ignore the Internet of things.
>
>
>
> By Internet of things I don't mean the buzzword, but the staggering number
> of devices that use HTTP as a universal substrate for getting data from A to
> B.
>
> No-one knows how many things are out there, but it's likely to be far, far
> higher than the number of browser users and web hosting providers (depending
> on who you ask and what source you use, the figure seems to be around 10-20
> billion devices, so it's also significantly larger than the number of people
> on the planet).
>
>
>
> These devices not only don't need stream multiplexing, flow control,
> prioritisation, unsolicited pushing of messages, Huffman-encoding of
> headers, and full orchestration and five part harmony, but don't have the
> resources to implement any of it.  Alternatively, if they do try and
> implement all of the complexity introduced by HTTP 2, they'll invariably do
> the absolute minimum required to allow whatever browser the developers are
> using for testing to connect, and no more, since the developers' goal is to
> create a functioning Internet-of-things device and not a Google-scale web
> service.
>
>
>
> In fact it's going to be impossible to create something on the level
> proposed by the HTTP 2 draft since we're talking about devices running on
> the likes of Cortex M3s, PICs, MSP430s, and ATmegas, which neither need, nor
> have the resources to implement, most of what's in the HTTP 2 draft.  The
> only thing that these devices need, and can support, is a substrate for
> moving a blob of data from A to B.  While something like this is indeed
> buried in HTTP 2 under layers and layers and layers and layers of
> complexity, screaming to get out, there doesn't seem to be any way to easily
> use it as such.
>
>
>
> So it looks like HTTP 2 really needs (at least) two different profiles, one
> for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP-
> as-a-substrate users.  The latter should have (or more accurately should
> *not*
>
> have) multiple streams and multiplexing, flow control, priorities,
> reprioritisation and dependencies, mandatory payload compression, most types
> of header compression, and many others.
>
>
>
> Now some of this can be faked (e.g. by setting SETTINGS_HEADER_TABLE_SIZE =
> 0, SETTINGS_ENABLE_PUSH = 0, SETTINGS_MAX_CONCURRENT_STREAMS = 1,
> SETTINGS_INITIAL_WINDOW_SIZE = 2^31-1, SETTINGS_COMPRESS_DATA = 0), but a
> lot of it can't, and in any case it shouldn't be necessary to change a whole
> pile of parameters just to get a basic HTTP service.
>
>
>
> This takes the enormous implementation complexity of HTTP 2 and profiles it
> for the Internet of things, allowing for the existing widespread use of
> HTTP- as-a-substrate, which is everything that's needed, and indeed
> possible, for vast numbers of devices.
>
>
>
> As an aside, how much of what's in the HTTP 2 draft is based on empirical
> data?  I know that the design of HTTP 1.1 was based on a large number of
> conference papers and other publications spread over many years that looked
> at HTTP issues and evaluated performance, but it's not so clear that HTTP 2
> has had the same amount of evaluation.  In particular it's implementing
> stacked TCP, which is never a good idea (see "Why TCP Over TCP Is A Bad
> Idea", http://sites.inka.de/~W1011/devel/tcp-tcp.html, or the discussion of
> the "SSH Channel Handbrake" starting at
> http://www.ietf.org/mail-archive/web/tls/current/msg03363.html), and then
> adding even more complexity like prioritisation and dependencies and
> weighting and reprioritisation.  Are the things in HTTP 2 based on any hard
> data - and by this I mean something more than just 'we measured SPDY on
> Google's servers and it was better' - or are they, if you'll excuse the
> expression, just a bunch of Google engineers hacking around?
>
>
>
>
>
> 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: Larry Masinter <[email-masked]>
Date: Mon, 5 May 2014 15:31:35 +0000

Perhaps an update to BCP 56 (aka http://www.ietf.org/rfc/rfc3205.txt ) "On the use of HTTP as a Substrate" and explicit warnings about the inappropriateness of HTTP/2 for these other applications belongs in the HTTP2 introduction.

Larry
--
http://larry.masinter.net

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 17:43:00 +0200

On 2014-05-05 17:31, Larry Masinter wrote:
> Perhaps an update to BCP 56 (akahttp://www.ietf.org/rfc/rfc3205.txt  ) “On the use of HTTP as a Substrate” and explicit warnings about the inappropriateness of HTTP/2 for these other applications belongs in the HTTP2 introduction.
>
> Larry
> ...

If HTTP/2 is inappropriate for a case where HTTP/1.1, that's a problem 
we need to solve. This WG is chartered to define a new protocol version 
that can *replace* HTTP/1.1.

So I'd really like to see something more concrete than "it's too 
complex". After all, correctly parsing text messages is complex as well, 
and that part is gone in HTTP/2.

Best regards, Julian

---

From: Erik Nygren <[email-masked]>
Date: Mon, 5 May 2014 11:50:34 -0400

I do think that the idea of a light-weight HTTP/2 profile may make sense.
There are some aspects of HTTP/2 that potentially make life easier for
embedded devices.  For example, the more binary-oriented structure may make
life easier for embedded devices.  Similarly, some elements of the data
exchange may actually make life easier in an IoT world.  Multiple streams,
PING, the data framing, and explicit end-of-stream notification, and
footers may all be useful in some telemetry applications.  (While not a
low-resource application, I'm aware of at least one proprietary system that
uses SPDY framing for telemetry where many of those elements came in handy.)

Is anyone trying to implement a light-weight embedded client/server as part
of the interop testing?
It seems like it would be valuable to understand which elements are hard in
a reduced-resource profile
(eg, requiring gzip seems unfortunate for these cases) and which elements
are actually helpful (many
of the other framing elements).  Some of the flow-control even seems like
it could be useful in some
limited resource environments.

       Erik

On Mon, May 5, 2014 at 10:50 AM, Yoav Nir <[email-masked]> wrote:

> Hi, Keith.
>
> I agree with the author that the HTTP/2 draft was driven by the needs of
> browser vendors and large hosting providers. It is not an ideal protocol
> for passing small blobs of data from A to B, but then neither is HTTP/1.1.
>
> I mostly agree with the list of things that the devices don’t need, except
> for the unsolicited pushing of messages. That seems useful for many of the
> use cases I’ve heard about for the IoT, and in fact is one of the features
> of CoAP.
>
> I don’t believe that HTTP/2 would become an optimal protocol for the needs
> of the devices even with the profile. At best it will be barely acceptable,
> much like HTTP/1.  This is by no means unique. Neither version of HTTP is
> ideal for downloading 1.5GB operating system updates either, but they’re
> both good enough that we don’t look for more appropriate protocols.
>
> I don’t know much about the Internet of Things and their requirements. But
> I don’t think it’s a good idea to have all data transfer on the Internet
> happen over the same 5-th layer protocol. The IETF has make CoAP for the
> use of such devices. Maybe it is appropriate, maybe it is not. And HTTP is
> certainly easy to deploy because there’s an HTTP library everywhere. But
> making HTTP fit everybody’s purpose would make it more complex, not less,
> because all endpoints would have to support the new profile (otherwise we
> get interop failures).
>
> I guess what I think is that HTTP/2 should be optimized for “the web”.
> Other use cases should either settle for the not-quite-optimal HTTP/2 (like
> the OS update download) or use a more appropriate protocol, which could be
> HTTP/1.x or something else.
>
> Yoav
>
> Someone recently pointed me to the HTTP2 specification, specifically
> draft- ietf-httpbis-http2-12.  My first reaction after a quick scan through
> it was "let me guess, this was driven entirely by browser vendors and large
> hosting providers".  HTTP2 adds, and changes, a large number of things that
> have been causing problems for web hosters and browser users, but seems to
> of devices that use HTTP as a universal substrate for getting data from A
> to B.
> higher than the number of browser users and web hosting providers
> (depending on who you ask and what source you use, the figure seems to be
> around 10-20 billion devices, so it's also significantly larger than the
> number of people on the planet).
>
>
> the likes of Cortex M3s, PICs, MSP430s, and ATmegas, which neither need,
> nor have the resources to implement, most of what's in the HTTP 2 draft.
> The only thing that these devices need, and can support, is a substrate for
> complexity, screaming to get out, there doesn't seem to be any way to
> easily use it as such.
>
>
> So it looks like HTTP 2 really needs (at least) two different profiles,
> one for web hosting/web browser users ("HTTP 2 is web scale!") and one for
> HTTP- as-a-substrate users.  The latter should have (or more accurately
> should *not*
> reprioritisation and dependencies, mandatory payload compression, most
> types of header compression, and many others.
>
>
> Now some of this can be faked (e.g. by setting SETTINGS_HEADER_TABLE_SIZE
> = 0, SETTINGS_ENABLE_PUSH = 0, SETTINGS_MAX_CONCURRENT_STREAMS = 1,
> lot of it can't, and in any case it shouldn't be necessary to change a
> whole pile of parameters just to get a basic HTTP service.
>
>
> This takes the enormous implementation complexity of HTTP 2 and profiles
> it for the Internet of things, allowing for the existing widespread use of
> Idea",http://sites.inka.de/~W1011/devel/tcp-tcp.html, or the discussion
> of the "SSH Channel Handbrake" starting at

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 May 2014 18:55:31 +0300

On May 5, 2014, at 6:43 PM, Julian Reschke <[email-masked]> wrote:

> If HTTP/2 is inappropriate for a case where HTTP/1.1, that's a problem we need to solve. This WG is chartered to define a new protocol version that can *replace* HTTP/1.1.

I think HTTP/1.1 is used in many places where it is not the most appropriate protocol, and we don’t have to make HTTP/2 cater to all of them.

> So I'd really like to see something more concrete than "it's too complex". After all, correctly parsing text messages is complex as well, and that part is gone in HTTP/2.

It’s not so much that HTTP/1 is much simpler. It’s that you can use a very simple subset of HTTP/1 - we’ve all talked to a web server by running telnet or “openssl s_client” and just typed in “GET / HTTP/1.0\n\n”. There is no way this easy to get stuff in HTTP/2.

Much of the popularity of passing everything over either HTTP or HTTPS is because of firewalls ([1]). This is getting to be less of a problem as firewalls are replaced by smarter firewalls, but people still prefer to use HTTP(S) because it works pretty much everywhere, which seems kind of wrong from a protocol perspective.

Yoav

[1] http://tools.ietf.org/html/draft-tschofenig-hourglass-00

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 May 2014 09:50:42 -0700

> I do think that the idea of a light-weight HTTP/2 profile may make sense.

This has been proposed, but it wasn't considered interesting enough to
specify.  See [1].

I'm not sure if anyone has attempted to build an HTTP/2 implementation
with some combination of minimal code size, processor usage, and
memory footprint.  As you point out here, it may be marginally more
work than HTTP/1.1, and some features may be too tempting to pass up.

HPACK with a table size of 0 is actually fairly simple to implement.
Though I'm not sure that it's significantly easier to handle than
HTTP/1.1, since the contents of the header fields are still
textual(*).

[1] tools.ietf.org/html/draft-montenegro-httpbis-http2-server-profiles

---

From: Cory Benfield <[email-masked]>
Date: Tue, 6 May 2014 10:09:21 +0100

On 5 May 2014 16:43, Julian Reschke <[email-masked]> wrote:
> If HTTP/2 is inappropriate for a case where HTTP/1.1, that's a problem we
> need to solve. This WG is chartered to define a new protocol version that
> can *replace* HTTP/1.1.
>
> So I'd really like to see something more concrete than "it's too complex".
> After all, correctly parsing text messages is complex as well, and that part
> is gone in HTTP/2.
>
> Best regards, Julian

I think that ship has sailed.

It's been my understanding and expectation that HTTP/2 is simply not
going to replace HTTP/1.1 wholly and completely. The complexity
increase in terms of quantity of code in any language that has basic
text-parsing functionality built-in (i.e. not C) from HTTP/1.1 to
HTTP/2 is so astronomical that it's staggering. Logic is added for
maintaining multiple sets of independent state (connection state,
stream state, per-stream header compression state, per frame
compression state). There are plenty of excellent gains to be achieved
by this increase in complexity, but we shouldn't be pretending that
HTTP/2 can be used everywhere HTTP/1.1 can.

HTTP/2 is also harder to debug than HTTP/1.1, even if we exclude the
fact that most HTTP/2 connections will be over TLS-with-PFS and will
therefore be painful to intercept and trace.

Certainly, in the world of client side HTTP libraries we're expecting
that HTTP/2 will not supplant HTTP/1.1. We're not even sure that
HTTP/2 will become the default.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 06 May 2014 22:37:26 +1200

I'm the author of the original commentary on the consequences of HTTP 2 for
embedded devices (or, in general, anything that isn't a web server or
browser), which was written to explore how a move to HTTP 2 would potentially
affect non-web-browser users.  To respond to some specific points:

>need to solve. This WG is chartered to define a new protocol version that can
>*replace* HTTP/1.1.

Combining the reply to this and other comments people have made about "let
them eat HTTP 1.1" or "HTTP 2 isn't meant for this":

HTTP 0.9 was designed to communicate web pages between web servers and web
browsers.  It ended up being used as a universal substrate for the Internet.

HTTP 1.0 was designed to communicate web pages between web servers and web
browsers.  It ended up being used as a universal substrate for the Internet.

HTTP 1.1 was designed to communicate web pages between web servers and web
browsers.  It ended up being used as a universal substrate for the Internet.

You can probably see where this is going...

So, no matter what the people designing HTTP 2.0 may want, it's going to end
up as the universal substrate for the Internet.  The only question is, will it
be a clearly-defined, well-specified substrate, or a bunch of not-very-
compatible vendor-specific hacks on the current 2.0 spec to try and trim it
down to something that functions as a universal substrate?

>Perhaps an update to BCP 56 (aka http://www.ietf.org/rfc/rfc3205.txt ) "On
>the use of HTTP as a Substrate" and explicit warnings about the
>inappropriateness of HTTP/2 for these other applications belongs in the HTTP2
>introduction.

Yeah, because that approach has worked so well to date...

>the pain I had with HPACK suggests it's a potential pain-point for a lot of
>others as well.

As the author of the original HPACK (see e.g.
https://www.freshports.org/archivers/hpack.non-usa.only/), maybe it could be
renamed so it doesn't give my original HPACK a bad name :-).

Peter.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 06 May 2014 12:50:13 +0000

In message <CAH_hAJEcBtjxu=[email-masked]>
, Cory Benfield writes:

>[...]

Or for that matter:  If HTTP/2 will be an improvement in the first place.

I've yet to see any numbers that justify technical cost of the added
complexity.

-- 
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: Cory Benfield <[email-masked]>
Date: Tue, 6 May 2014 14:35:23 +0100

> I've yet to see any numbers that justify technical cost of the added

I'm not quite as pessimistic as you are, Poul-Henning. I'm sure there
will be some specific use-cases where HTTP/2 is a win, which is why I
want client libraries in Python to have access to it. But I agree, it
seems that there are going to be a reasonable number of use-cases
where HTTP/2 is less effective than HTTP/1.1.

---

From: <[email-masked]>
Date: Tue, 6 May 2014 16:49:06 +0000

On Monday,05 May 2014 18:51, [email-masked]<mailto:[email-masked]> wrote:
> On 5 May 2014 08:50, Erik Nygren <[email-masked]<mailto:[email-masked]>> wrote:

> This has been proposed, but it wasn't considered interesting enough to specify.  See [1].

> [1] tools.ietf.org/html/draft-montenegro-httpbis-http2-server-profiles

I could only find one place this draft was even mentioned on the mailing list [1]. Apparently nobody responded to Gabriel and Roberto?  Is that the definition of not interesting?  For the record, I'm now expressing an interest :)

I think it sounds like a great idea, though it doesn't solve the problem for non-TLS case.

As Peter pointed out in his review, an endpoint can "simplify" its implementation by setting the SETTINGS_* to appropriate values.  But some of it still can't be simplified e.g. in HPACK we can set the table size to 0, but we can't disable Huffman. Why not?

I think the default SETTINGS_* should be at the levels similar to what Gabriel and Roberto proposed to call the "constrained server profile" [3].  This would only affect the connection for one RTT until the server is able to upgrade its settings to the "normal server profile".  Changing the SETTINGS_* in the other direction would "overrun any of the server's preferences" (as Gabriel and Roberto called it).

(For the TLS case I think the Gabriel and Roberto's idea is the better way as you can immediately start at the server's settings preferences.)

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/1141.html

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

[3] http://tools.ietf.org/html/draft-montenegro-httpbis-http2-server-profiles-00#section-2