New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hpack optimization #587

Closed
martinthomson opened this Issue Aug 8, 2014 · 27 comments

Comments

Projects
None yet
7 participants
@martinthomson
Member

martinthomson commented Aug 8, 2014

Greg did some testing based on our small sample data and found that adding values to the static table improve compression a little.

"accept-ranges","bytes"
"accept","/"
"age","0"
"allow","GET"
"cache-control","no-cache"
"content-disposition","attachment"
"content-encoding","gzip"
"content-length","0"
"content-type","application/x-javascript"
"vary","Accept-Encoding"

This achieved 0.9% saving.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Aug 8, 2014

Member

Note that this saving isn't much, nor is it well supported by data, and it's therefore only worth considering if we need to make other breaking changes in the protocol.

Member

martinthomson commented Aug 8, 2014

Note that this saving isn't much, nor is it well supported by data, and it's therefore only worth considering if we need to make other breaking changes in the protocol.

@gregw

This comment has been minimized.

Show comment
Hide comment
@gregw

gregw Aug 8, 2014

Note that the "accept","/" should be "accept","/"

gregw commented Aug 8, 2014

Note that the "accept","/" should be "accept","/"

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 13, 2014

Member

application/x-javascript is non-standard; I don't think we want to encourage that.

text/html; charset=utf8 might be more the go.

A few more:

  • If we're going to include expect, why not 100-continue?
  • If we're going to include access-control-allow-origin, it'd be nice to confirm with the W3C that this is going to stick (they've had a few tries at CORS), and that there's not anything else on the horizon.
  • If-Unmodified-Since? Really?
  • Max-Forwards? Considering we're no longer hop-by-hop, that's a good trick.
  • Refresh is non-standard, and badly interoperable. Shouldn't be encouraged.
  • Uhhhhh, we don't allow Transfer-Encoding; why is it in the static table?
Member

mnot commented Aug 13, 2014

application/x-javascript is non-standard; I don't think we want to encourage that.

text/html; charset=utf8 might be more the go.

A few more:

  • If we're going to include expect, why not 100-continue?
  • If we're going to include access-control-allow-origin, it'd be nice to confirm with the W3C that this is going to stick (they've had a few tries at CORS), and that there's not anything else on the horizon.
  • If-Unmodified-Since? Really?
  • Max-Forwards? Considering we're no longer hop-by-hop, that's a good trick.
  • Refresh is non-standard, and badly interoperable. Shouldn't be encouraged.
  • Uhhhhh, we don't allow Transfer-Encoding; why is it in the static table?
@RobbySimpson

This comment has been minimized.

Show comment
Hide comment
@RobbySimpson

RobbySimpson Sep 26, 2014

I support fixing this (as many have mentioned, there is no reason to have empty values in the static table unless it just doesn't make sense semantically).

Also, I mentioned on the list that "allow" is out-of-order lexically. Should this be a separate issue or can we track here as part of "breaking" hpack changes?

RobbySimpson commented Sep 26, 2014

I support fixing this (as many have mentioned, there is no reason to have empty values in the static table unless it just doesn't make sense semantically).

Also, I mentioned on the list that "allow" is out-of-order lexically. Should this be a separate issue or can we track here as part of "breaking" hpack changes?

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 7, 2014

Member

Closing for now; labeled revisit-upon-change to allow reopening when there are more substantial changes justified.

Member

mnot commented Oct 7, 2014

Closing for now; labeled revisit-upon-change to allow reopening when there are more substantial changes justified.

@mnot mnot closed this Oct 7, 2014

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 13, 2014

Member

Possibly extraneous values:

  • transfer-encoding (not in http/2)
  • retry-after
  • proxy-authenticate (only sent as a challenge)
  • www-authenticate (only sent as a challenge)
  • max-forwards
  • if-unmodified-since
  • if-match
  • from (huffman codes to 23 bits; not common)
  • content-disposition (sent rarely)
  • :status 204
  • :status 206
  • :status 400 (errors are exceptional, and usually stop conditions anyway)
  • :status 404 (ditto)
  • :status 500 (ditto)
  • :scheme http
  • :path /index.html
  • :method POST (when used, the request is big anyway)
  • accept-charset (not commonly used any more)
  • access-control-allow-origin (it's wordy, but it's a response header, and only one of many CORS headers)
  • date (huffman codes to 21 bits; is response-oriented)
  • etag (huffman codes to 21 bits; is response-oriented)
  • if-range
  • link (huffman codes to 24 bits; is response-oriented)
  • refresh (not standard, not evenly supported)
  • via (it's already short; huffman codes to 17 bits)

That's 25 more slots for dynamic headers (if all are removed from the static table)

Note: bias is against response headers, since request have more "punch" for performance. Also against headers that are only sent once (e.g., as a challenge). Focus of the static table should be getting the first few requests going, nothing more.

Member

mnot commented Oct 13, 2014

Possibly extraneous values:

  • transfer-encoding (not in http/2)
  • retry-after
  • proxy-authenticate (only sent as a challenge)
  • www-authenticate (only sent as a challenge)
  • max-forwards
  • if-unmodified-since
  • if-match
  • from (huffman codes to 23 bits; not common)
  • content-disposition (sent rarely)
  • :status 204
  • :status 206
  • :status 400 (errors are exceptional, and usually stop conditions anyway)
  • :status 404 (ditto)
  • :status 500 (ditto)
  • :scheme http
  • :path /index.html
  • :method POST (when used, the request is big anyway)
  • accept-charset (not commonly used any more)
  • access-control-allow-origin (it's wordy, but it's a response header, and only one of many CORS headers)
  • date (huffman codes to 21 bits; is response-oriented)
  • etag (huffman codes to 21 bits; is response-oriented)
  • if-range
  • link (huffman codes to 24 bits; is response-oriented)
  • refresh (not standard, not evenly supported)
  • via (it's already short; huffman codes to 17 bits)

That's 25 more slots for dynamic headers (if all are removed from the static table)

Note: bias is against response headers, since request have more "punch" for performance. Also against headers that are only sent once (e.g., as a challenge). Focus of the static table should be getting the first few requests going, nothing more.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 13, 2014

Member

Yeah, if the intent is to trim this down; this is a good list. I would probably keep Date, because it's in every response, and one isn't going to hurt that much. I'm also somewhat inclined to keep If-Unmodified-Since, though I can't substantiate that, other than to note that I see it lots.

Member

martinthomson commented Oct 13, 2014

Yeah, if the intent is to trim this down; this is a good list. I would probably keep Date, because it's in every response, and one isn't going to hurt that much. I'm also somewhat inclined to keep If-Unmodified-Since, though I can't substantiate that, other than to note that I see it lots.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 13, 2014

Member

What UAs do you see If-Unmodified-Since from?

Member

mnot commented Oct 13, 2014

What UAs do you see If-Unmodified-Since from?

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 13, 2014

Member

@hruellan it'd be interesting to see numbers on how removing those affects overall performance (hint, hint)...

Member

mnot commented Oct 13, 2014

@hruellan it'd be interesting to see numbers on how removing those affects overall performance (hint, hint)...

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 13, 2014

Member

Why would you assume that it's a UA. I'm talking clients. Though If-None-Match is certainly far more commonplace there.

Member

martinthomson commented Oct 13, 2014

Why would you assume that it's a UA. I'm talking clients. Though If-None-Match is certainly far more commonplace there.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 13, 2014

Member

So you're saying intermediaries are generating it? So, what are the Via headers, then?

Member

mnot commented Oct 13, 2014

So you're saying intermediaries are generating it? So, what are the Via headers, then?

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 13, 2014

Member

I inferred UA == browser. I meant embedded clients of other forms, not intermediaries.

Member

martinthomson commented Oct 13, 2014

I inferred UA == browser. I meant embedded clients of other forms, not intermediaries.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Oct 14, 2014

Member

Ah, you've been infected by the browser ppl. RTFM - http://httpwg.github.io/specs/rfc7230.html#operation

:)

Member

mnot commented Oct 14, 2014

Ah, you've been infected by the browser ppl. RTFM - http://httpwg.github.io/specs/rfc7230.html#operation

:)

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 14, 2014

Member

I've never understood that distinction to be relevant. And the idea that a client acts for a user (i.e., is a user agent) in the general sense is a bit off too.

Member

martinthomson commented Oct 14, 2014

I've never understood that distinction to be relevant. And the idea that a client acts for a user (i.e., is a user agent) in the general sense is a bit off too.

@hruellan

This comment has been minimized.

Show comment
Hide comment
@hruellan

hruellan Oct 14, 2014

Contributor

I started doing some tests.
Basically, reducing the static table decrease compression when the dynamic table is small, but improves it when the dynamic table is large. The turning point is between 4K and 8K.
Mostly the compression changes are small (1.5% increase or decrease).
However for the HR test suite, the size increase for requests with a 1K table is greater than 5%. I'd like to understand the reason and I'm going to investigate more on this point.

Contributor

hruellan commented Oct 14, 2014

I started doing some tests.
Basically, reducing the static table decrease compression when the dynamic table is small, but improves it when the dynamic table is large. The turning point is between 4K and 8K.
Mostly the compression changes are small (1.5% increase or decrease).
However for the HR test suite, the size increase for requests with a 1K table is greater than 5%. I'd like to understand the reason and I'm going to investigate more on this point.

@hruellan

This comment has been minimized.

Show comment
Hide comment
@hruellan

hruellan Oct 15, 2014

Contributor

I dug a bit deeper, and found the following.
For requests, the negative impact comes from removing:

  • :scheme: http
  • accept-charset
    The removal of ":scheme:http" has a large impact for a 1K table (4% increase in size) and a small impact for a 2K table (.5% increase in size).
    The removal of "accept-charset" has some impact for a 1K table (1.5% increase in size) and a small impact for a 2K table (.25% increase in size).

For responses, the negative impact comes from removing:

  • date
  • via
    The removal of these two header names mostly impact the compaction when the dynamic table size is 1K (1% increase in size) or 2K (.5% increase in size). The relative impact should be roughly the same.

I think that ":scheme:http" and "accept-charset" should be removed from the static table.
For "date" and "via", I think it depends on the tradeoff we want to make.

Contributor

hruellan commented Oct 15, 2014

I dug a bit deeper, and found the following.
For requests, the negative impact comes from removing:

  • :scheme: http
  • accept-charset
    The removal of ":scheme:http" has a large impact for a 1K table (4% increase in size) and a small impact for a 2K table (.5% increase in size).
    The removal of "accept-charset" has some impact for a 1K table (1.5% increase in size) and a small impact for a 2K table (.25% increase in size).

For responses, the negative impact comes from removing:

  • date
  • via
    The removal of these two header names mostly impact the compaction when the dynamic table size is 1K (1% increase in size) or 2K (.5% increase in size). The relative impact should be roughly the same.

I think that ":scheme:http" and "accept-charset" should be removed from the static table.
For "date" and "via", I think it depends on the tradeoff we want to make.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 15, 2014

Member

I'd think that we might make some sort of value-judgment regarding some of these. The judgment implicit in removing ":scheme: http" might be a little strong for me to take on, but I hope that "via" and "accept-charset" are relatively uncontroversial. I think that "date" is worth keeping though.

Member

martinthomson commented Oct 15, 2014

I'd think that we might make some sort of value-judgment regarding some of these. The judgment implicit in removing ":scheme: http" might be a little strong for me to take on, but I hope that "via" and "accept-charset" are relatively uncontroversial. I think that "date" is worth keeping though.

@grmocg

This comment has been minimized.

Show comment
Hide comment
@grmocg

grmocg Oct 15, 2014

Contributor

And of course, none of this needs removal if we switch the indexing back.

On Wed, Oct 15, 2014 at 3:50 PM, Martin Thomson notifications@github.com
wrote:

I'd think that we might make some sort of value-judgment regarding some of
these. The judgment implicit in removing ":scheme: http" might be a little
strong for me to take on, but I hope that "via" and "accept-charset" are
relatively uncontroversial. I think that "date" is worth keeping though.


Reply to this email directly or view it on GitHub
#587 (comment).

Contributor

grmocg commented Oct 15, 2014

And of course, none of this needs removal if we switch the indexing back.

On Wed, Oct 15, 2014 at 3:50 PM, Martin Thomson notifications@github.com
wrote:

I'd think that we might make some sort of value-judgment regarding some of
these. The judgment implicit in removing ":scheme: http" might be a little
strong for me to take on, but I hope that "via" and "accept-charset" are
relatively uncontroversial. I think that "date" is worth keeping though.


Reply to this email directly or view it on GitHub
#587 (comment).

@RobbySimpson

This comment has been minimized.

Show comment
Hide comment
@RobbySimpson

RobbySimpson Oct 16, 2014

I completely agree w Martin here.

Sent from my iPhone - thus the tpyos and brvty

On Oct 16, 2014, at 12:50 AM, "Martin Thomson" <notifications@github.commailto:notifications@github.com> wrote:

I'd think that we might make some sort of value-judgment regarding some of these. The judgment implicit in removing ":scheme: http" might be a little strong for me to take on, but I hope that "via" and "accept-charset" are relatively uncontroversial. I think that "date" is worth keeping though.


Reply to this email directly or view it on GitHubhttps://github.com/http2/http2-spec/issues/587#issuecomment-59289492.

RobbySimpson commented Oct 16, 2014

I completely agree w Martin here.

Sent from my iPhone - thus the tpyos and brvty

On Oct 16, 2014, at 12:50 AM, "Martin Thomson" <notifications@github.commailto:notifications@github.com> wrote:

I'd think that we might make some sort of value-judgment regarding some of these. The judgment implicit in removing ":scheme: http" might be a little strong for me to take on, but I hope that "via" and "accept-charset" are relatively uncontroversial. I think that "date" is worth keeping though.


Reply to this email directly or view it on GitHubhttps://github.com/http2/http2-spec/issues/587#issuecomment-59289492.

@gregw

This comment has been minimized.

Show comment
Hide comment
@gregw

gregw Oct 23, 2014

Here is a proposal for a trimmed static table that:

  • Is only 31 entries, so that 31 single byte encodings are available for dynamic fields and field names removes most of the fields nominated in #587 as unneccesary
  • adds the values suggest in #597 and some more
  • The first 14 slots are used for the most frequent field names with variable values that are unlikely to be indexed, so they can be encoded as 1 byte in a literal with a 4+ name index.
  • Adds the most frequent value to all fields where it makes sense.
  • Adds some possible useful values where it makes sense
Index Header Value
1 :authority localhost
2 :path /
3 authorization
4 content-length 0
5 content-type application/x-javascript
6 date Thu, 01 Jan 1970 00:00:00 GMT
7 etag
8 expires Thu, 01 Jan 1970 00:00:00 GMT
9 if-match
10 if-modified-since Thu, 01 Jan 1970 00:00:00 GMT
11 last-modified Thu, 01 Jan 1970 00:00:00 GMT
12 location
13 referer
14 www-authenticate
15 :method GET
16 :scheme https
17 :status 200
18 accept /
19 accept-encoding gzip, deflate
20 accept-language
21 accept-ranges bytes
22 allow GET
23 cache-control no-cache
24 content-encoding gzip
25 content-language
26 cookie
27 range
28 server
29 set-cookie
30 user-agent
31 vary accept-encoding

gregw commented Oct 23, 2014

Here is a proposal for a trimmed static table that:

  • Is only 31 entries, so that 31 single byte encodings are available for dynamic fields and field names removes most of the fields nominated in #587 as unneccesary
  • adds the values suggest in #597 and some more
  • The first 14 slots are used for the most frequent field names with variable values that are unlikely to be indexed, so they can be encoded as 1 byte in a literal with a 4+ name index.
  • Adds the most frequent value to all fields where it makes sense.
  • Adds some possible useful values where it makes sense
Index Header Value
1 :authority localhost
2 :path /
3 authorization
4 content-length 0
5 content-type application/x-javascript
6 date Thu, 01 Jan 1970 00:00:00 GMT
7 etag
8 expires Thu, 01 Jan 1970 00:00:00 GMT
9 if-match
10 if-modified-since Thu, 01 Jan 1970 00:00:00 GMT
11 last-modified Thu, 01 Jan 1970 00:00:00 GMT
12 location
13 referer
14 www-authenticate
15 :method GET
16 :scheme https
17 :status 200
18 accept /
19 accept-encoding gzip, deflate
20 accept-language
21 accept-ranges bytes
22 allow GET
23 cache-control no-cache
24 content-encoding gzip
25 content-language
26 cookie
27 range
28 server
29 set-cookie
30 user-agent
31 vary accept-encoding
@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 23, 2014

Member

I don't see any value in the dates, unless you want to put expires at 2050 or something like that. I can see servers exploiting the limits that clients put on caches.

Some numbers based on this table would be interesting.

Member

martinthomson commented Oct 23, 2014

I don't see any value in the dates, unless you want to put expires at 2050 or something like that. I can see servers exploiting the limits that clients put on caches.

Some numbers based on this table would be interesting.

@reschke

This comment has been minimized.

Show comment
Hide comment
@reschke

reschke Oct 23, 2014

Contributor

Where does the information that "application/x-javascript" is the most frequent type come from?

Contributor

reschke commented Oct 23, 2014

Where does the information that "application/x-javascript" is the most frequent type come from?

@gregw

This comment has been minimized.

Show comment
Hide comment
@gregw

gregw Oct 23, 2014

Martin & Julian,

These values have not been rigorously determined as I don't have a good
representative data set to work from. They are a best guess from data I
had at hand and gut feel.

I agree that the date values are probably marginally useful, but I have
seen 1 Jan 1970 as a moderately frequent value in some circumstances.
Perhaps 2050 for some might be better? Probably not going to get huge
benefit out of these as any common value can cheaply be put in the dynamic
table - so unless there is popular outcry for 1 Jan 1970, I'm happy to
blank.

Ditto for the javascript value. I think in the circumstance this can most
help with it is either going to be css of js files are sent early in a
conversation. Images also, but there are too many values there. So I
picked js as something that at least will do no harm, but happy to null it
if it appears a bit arbitrary (which it is :)

I think most benefits from the table refactor is reducing size so that
dynamic headers get a go and moving the known names to early in the table
so they get 1 byte name indexes.

cheers

cheers

On 23 October 2014 16:57, reschke notifications@github.com wrote:

Where does the information that "application/x-javascript" is the most
frequent type come from?


Reply to this email directly or view it on GitHub
#587 (comment).

Greg Wilkins gregw@intalio.com @ Webtide - an Intalio subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.

gregw commented Oct 23, 2014

Martin & Julian,

These values have not been rigorously determined as I don't have a good
representative data set to work from. They are a best guess from data I
had at hand and gut feel.

I agree that the date values are probably marginally useful, but I have
seen 1 Jan 1970 as a moderately frequent value in some circumstances.
Perhaps 2050 for some might be better? Probably not going to get huge
benefit out of these as any common value can cheaply be put in the dynamic
table - so unless there is popular outcry for 1 Jan 1970, I'm happy to
blank.

Ditto for the javascript value. I think in the circumstance this can most
help with it is either going to be css of js files are sent early in a
conversation. Images also, but there are too many values there. So I
picked js as something that at least will do no harm, but happy to null it
if it appears a bit arbitrary (which it is :)

I think most benefits from the table refactor is reducing size so that
dynamic headers get a go and moving the known names to early in the table
so they get 1 byte name indexes.

cheers

cheers

On 23 October 2014 16:57, reschke notifications@github.com wrote:

Where does the information that "application/x-javascript" is the most
frequent type come from?


Reply to this email directly or view it on GitHub
#587 (comment).

Greg Wilkins gregw@intalio.com @ Webtide - an Intalio subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 23, 2014

Member

I can see two ways of justifying these: run some compression tests and show some improvement (it probably won't be much, but statistical significance would be nice); or, find some information on relative frequency.

Member

martinthomson commented Oct 23, 2014

I can see two ways of justifying these: run some compression tests and show some improvement (it probably won't be much, but statistical significance would be nice); or, find some information on relative frequency.

@reschke

This comment has been minimized.

Show comment
Hide comment
@reschke

reschke Oct 23, 2014

Contributor

My main concern with x-javascript is that it creates an incentive to use an unregistered media type.

Contributor

reschke commented Oct 23, 2014

My main concern with x-javascript is that it creates an incentive to use an unregistered media type.

@gregw

This comment has been minimized.

Show comment
Hide comment
@gregw

gregw Oct 23, 2014

On 23 October 2014 19:41, reschke notifications@github.com wrote:

My main concern with x-javascript is that it creates an incentive to use
an unregistered media type.

So "text/html; charset=UTF8" ? Probably not the most frequent, but
registered and is at least not uncommon.
or no value?

For the dates, I note that a lot of google sites are using "Fri, 01 Jan
1990 00:00:00 GMT" as an already expired date. But many other sites are
using expired: -1. So perhaps no date value.... and that will encourage a
binary date extension.

cheers

Greg Wilkins gregw@intalio.com @ Webtide - an Intalio subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.

gregw commented Oct 23, 2014

On 23 October 2014 19:41, reschke notifications@github.com wrote:

My main concern with x-javascript is that it creates an incentive to use
an unregistered media type.

So "text/html; charset=UTF8" ? Probably not the most frequent, but
registered and is at least not uncommon.
or no value?

For the dates, I note that a lot of google sites are using "Fri, 01 Jan
1990 00:00:00 GMT" as an already expired date. But many other sites are
using expired: -1. So perhaps no date value.... and that will encourage a
binary date extension.

cheers

Greg Wilkins gregw@intalio.com @ Webtide - an Intalio subsidiary
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.

@RobbySimpson

This comment has been minimized.

Show comment
Hide comment
@RobbySimpson

RobbySimpson Oct 23, 2014

I've got some spare cycles (long flight coming up) and would not mind doing some frequency analysis (ideally, weighted by compression). Where are some good traces for me to use? I looked in https://github.com/http2/http_samples — is there a particular set we've been using in the past?

From: Martin Thomson <notifications@github.commailto:notifications@github.com>
Reply-To: http2/http2-spec <reply@reply.github.commailto:reply@reply.github.com>
Date: Thursday, October 23, 2014 at 2:55 AM
To: http2/http2-spec <http2-spec@noreply.github.commailto:http2-spec@noreply.github.com>
Cc: Charles Simpson <Robby.Simpson@GE.commailto:Robby.Simpson@GE.com>
Subject: Re: [http2-spec] Hpack optimization (#587)

I can see two ways of justifying these: run some compression tests and show some improvement (it probably won't be much, but statistical significance would be nice); or, find some information on relative frequency.


Reply to this email directly or view it on GitHubhttps://github.com/http2/http2-spec/issues/587#issuecomment-60199478.

RobbySimpson commented Oct 23, 2014

I've got some spare cycles (long flight coming up) and would not mind doing some frequency analysis (ideally, weighted by compression). Where are some good traces for me to use? I looked in https://github.com/http2/http_samples — is there a particular set we've been using in the past?

From: Martin Thomson <notifications@github.commailto:notifications@github.com>
Reply-To: http2/http2-spec <reply@reply.github.commailto:reply@reply.github.com>
Date: Thursday, October 23, 2014 at 2:55 AM
To: http2/http2-spec <http2-spec@noreply.github.commailto:http2-spec@noreply.github.com>
Cc: Charles Simpson <Robby.Simpson@GE.commailto:Robby.Simpson@GE.com>
Subject: Re: [http2-spec] Hpack optimization (#587)

I can see two ways of justifying these: run some compression tests and show some improvement (it probably won't be much, but statistical significance would be nice); or, find some information on relative frequency.


Reply to this email directly or view it on GitHubhttps://github.com/http2/http2-spec/issues/587#issuecomment-60199478.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment