H2 Implementation Debug State URI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

H2 Implementation Debug State URI

Cory Benfield
All,

During the HTTP workshop earlier this week, several HTTP/2 implementers expressed a desire to extract information about the state of the H2 connection from the perspective of their peer. This would be extremely useful when developing, debugging, and testing implementations: given that HTTP/2 is so highly stateful the vast majority of interoperability issues come from implementations disagreeing about what the state of the connection is (usually flow control windows!).

Brad Fitzpatrick and I ended up prototyping a sample approach for getting this information out of server implementations, based on issuing a GET request to a specific well-known URI. This GET would return a JSON document that contains various different pieces of information from inside the implementation, such as window sizes and stream states. In addition, to help debug flow control concerns, the response headers also include information about flow control windows (because if a server believes it is blocked behind flow control it can’t send the JSON document, but it can send the response headers). Examples of this behaviour are available at https://http2.golang.org/.well-known/h2interop/state and https://shootout.lukasa.co.uk/.well-known/h2interop/state.

The consensus amongst the implementers we spoke to were that this was a good idea, and it would be good to collaborate on the information that should be exposed here. For most HTTP/2 implementers one of the most natural ways to collaborate on something like this is to use an Internet Draft. For that reason, I have submitted the outline of a draft that essentially defines what Brad and I have already done. You can find this draft here: https://tools.ietf.org/html/draft-benfield-http2-debug-state-00

I have no expectation that this will become a WG document. However, I’d like to bring it to the attention of the working group to ensure that as many implementers as possible can provide feedback on whether this kind of approach is valuable or not, and what information they’d like made available in this kind of mode.

For anyone who wants to contribute, raise issues, or otherwise help with the draft, it is hosted on GitHub: https://github.com/python-hyper/draft-http2-debug-state. Issues and pull requests are more than welcome, as is feedback on this list.

Thanks,

Cory
Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Stefan Eissing
Thanks, Cory!. Apache will offer this as a configurable handler and I will make a beta available via github soon. Currently outputs lacks individual streams and looks like this:
{
  "settings": {
    "SETTINGS_MAX_CONCURRENT_STREAMS": 100,
    "SETTINGS_MAX_FRAME_SIZE": 16384,
    "SETTINGS_INITIAL_WINDOW_SIZE": 65535,
    "SETTINGS_ENABLE_PUSH": 1
  },
  "connFlowIn": 2147483647,
  "connFlowOut": 12571993,
  "sentGoAway": 0,
  "in": {
    "requests": 63,
    "resets": 0,
    "frames": 134,
    "octets": 3831
  },
  "out": {
    "responses": 62,
    "frames": 130,
    "octets": 13754
  },
  "push": {
    "cacheDigest": "AQib_wA",
    "promises": 1,
    "submits": 1,
    "resets": 0
  }
}

-Stefan

> Am 28.07.2016 um 14:38 schrieb Cory Benfield <[hidden email]>:
>
> All,
>
> During the HTTP workshop earlier this week, several HTTP/2 implementers expressed a desire to extract information about the state of the H2 connection from the perspective of their peer. This would be extremely useful when developing, debugging, and testing implementations: given that HTTP/2 is so highly stateful the vast majority of interoperability issues come from implementations disagreeing about what the state of the connection is (usually flow control windows!).
>
> Brad Fitzpatrick and I ended up prototyping a sample approach for getting this information out of server implementations, based on issuing a GET request to a specific well-known URI. This GET would return a JSON document that contains various different pieces of information from inside the implementation, such as window sizes and stream states. In addition, to help debug flow control concerns, the response headers also include information about flow control windows (because if a server believes it is blocked behind flow control it can’t send the JSON document, but it can send the response headers). Examples of this behaviour are available at https://http2.golang.org/.well-known/h2interop/state and https://shootout.lukasa.co.uk/.well-known/h2interop/state.
>
> The consensus amongst the implementers we spoke to were that this was a good idea, and it would be good to collaborate on the information that should be exposed here. For most HTTP/2 implementers one of the most natural ways to collaborate on something like this is to use an Internet Draft. For that reason, I have submitted the outline of a draft that essentially defines what Brad and I have already done. You can find this draft here: https://tools.ietf.org/html/draft-benfield-http2-debug-state-00
>
> I have no expectation that this will become a WG document. However, I’d like to bring it to the attention of the working group to ensure that as many implementers as possible can provide feedback on whether this kind of approach is valuable or not, and what information they’d like made available in this kind of mode.
>
> For anyone who wants to contribute, raise issues, or otherwise help with the draft, it is hosted on GitHub: https://github.com/python-hyper/draft-http2-debug-state. Issues and pull requests are more than welcome, as is feedback on this list.
>
> Thanks,
>
> Cory


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Alcides Viamontes E-2
This is a nice debugging asset! But looking forward to a more generic mechanism that could be used leveraged by application servers and by web-applications, it could be possible to just leverage the "Forwarded" HTTP extension (RFC 7239). 

We do something like that for some bits and pieces : https://www.shimmercat.com/en/info/articles/forwarded-header/ 

On Thu, Jul 28, 2016 at 4:00 PM, Stefan Eissing <[hidden email]> wrote:
Thanks, Cory!. Apache will offer this as a configurable handler and I will make a beta available via github soon. Currently outputs lacks individual streams and looks like this:
{
  "settings": {
    "SETTINGS_MAX_CONCURRENT_STREAMS": 100,
    "SETTINGS_MAX_FRAME_SIZE": 16384,
    "SETTINGS_INITIAL_WINDOW_SIZE": 65535,
    "SETTINGS_ENABLE_PUSH": 1
  },
  "connFlowIn": <a href="tel:2147483647" value="+12147483647">2147483647,
  "connFlowOut": 12571993,
  "sentGoAway": 0,
  "in": {
    "requests": 63,
    "resets": 0,
    "frames": 134,
    "octets": 3831
  },
  "out": {
    "responses": 62,
    "frames": 130,
    "octets": 13754
  },
  "push": {
    "cacheDigest": "AQib_wA",
    "promises": 1,
    "submits": 1,
    "resets": 0
  }
}

-Stefan

> Am 28.07.2016 um 14:38 schrieb Cory Benfield <[hidden email]>:
>
> All,
>
> During the HTTP workshop earlier this week, several HTTP/2 implementers expressed a desire to extract information about the state of the H2 connection from the perspective of their peer. This would be extremely useful when developing, debugging, and testing implementations: given that HTTP/2 is so highly stateful the vast majority of interoperability issues come from implementations disagreeing about what the state of the connection is (usually flow control windows!).
>
> Brad Fitzpatrick and I ended up prototyping a sample approach for getting this information out of server implementations, based on issuing a GET request to a specific well-known URI. This GET would return a JSON document that contains various different pieces of information from inside the implementation, such as window sizes and stream states. In addition, to help debug flow control concerns, the response headers also include information about flow control windows (because if a server believes it is blocked behind flow control it can’t send the JSON document, but it can send the response headers). Examples of this behaviour are available at https://http2.golang.org/.well-known/h2interop/state and https://shootout.lukasa.co.uk/.well-known/h2interop/state.
>
> The consensus amongst the implementers we spoke to were that this was a good idea, and it would be good to collaborate on the information that should be exposed here. For most HTTP/2 implementers one of the most natural ways to collaborate on something like this is to use an Internet Draft. For that reason, I have submitted the outline of a draft that essentially defines what Brad and I have already done. You can find this draft here: https://tools.ietf.org/html/draft-benfield-http2-debug-state-00
>
> I have no expectation that this will become a WG document. However, I’d like to bring it to the attention of the working group to ensure that as many implementers as possible can provide feedback on whether this kind of approach is valuable or not, and what information they’d like made available in this kind of mode.
>
> For anyone who wants to contribute, raise issues, or otherwise help with the draft, it is hosted on GitHub: https://github.com/python-hyper/draft-http2-debug-state. Issues and pull requests are more than welcome, as is feedback on this list.
>
> Thanks,
>
> Cory





--
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is a property of Zunzun AB)
Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Poul-Henning Kamp
In reply to this post by Cory Benfield
--------
In message <[hidden email]>, Cory Benfield writes:

>Brad Fitzpatrick and I ended up prototyping a sample approach for
>getting this information out of server implementations, based on issuing
>a GET request to a specific well-known URI. This GET would return a JSON
>document [...]

>https://http2.golang.org/.well-known/h2interop/state and
>https://shootout.lukasa.co.uk/.well-known/h2interop/state.

>draft here:
>https://tools.ietf.org/html/draft-benfield-http2-debug-state-00

As I said in the workshop, this has security considerations.

A lot of people tend to forget that client side proxies exist in H2.

They may not be popular, they may not be COTS (yet), but nanny-proxies
are not going to go away when they are mandated by law in an
increasing number of contexts.

For security reasons we cannot allow this well-known-URL to be
fetched through a shared client-side proxy.

Exporting the HPACK header table gives you the other clients
cookies etc, and even exporting the streams table would
probably leak more info than acceptable.

Short of a dedicated H2 frame to get this, I don't know of any
method which can enforce this being used only hop-to-hop, which
is the only way it can be used safely.

So at the very least this needs to be firmly turned off by default
and have a major warning posted on the enabling button.

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

Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Cory Benfield

On 5 Aug 2016, at 09:01, Poul-Henning Kamp <[hidden email]> wrote:

So at the very least this needs to be firmly turned off by default
and have a major warning posted on the enabling button.


I agree with you, and there’s some extensive conversation going on on the GitHub page about the way this interacts with proxies. In the short term, draft-01 will contain a strong admonition not to use the “hpack" key on uncontrolled networks.

The longer term question is about how to deal with the fact that a misbehaving H2 connection could be the result of the H2 state in any of the hops on the connection. For example, if you have a connection that goes: client -> forward proxy A -> reverse proxy B -> origin server, and all those hops are H2, you really need to see H2 state in *all* of them to understand what the problem might be. However, the well-known URI doesn’t allow for that kind of debugging without requiring the awkward step of needing proxies to rewrite the response body to include their own data.

A frame might be better, but then we lose some of the introspective power, as well as somewhat increasing the overhead of an implementation deploying this kind of support. Certainly it’s much harder to see the value of it when you can’t easily demo in a browser.

Cory
Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Poul-Henning Kamp
--------
In message <[hidden email]>, Cory Benfield writes:

>You're going to love my time machine:

Cool.

Maybe it is one of those places where crypto could be useful:

Make the request contain the ID of a pre-shared-key.  If its on
the list you get the full monty, if not, you only get a safe summary.

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

Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Cory Benfield

> On 5 Aug 2016, at 10:12, Poul-Henning Kamp <[hidden email]> wrote:
>
> Maybe it is one of those places where crypto could be useful:
>
> Make the request contain the ID of a pre-shared-key.  If its on
> the list you get the full monty, if not, you only get a safe summary.

So that kind of model certainly could work. At a certain point, though, one wonders if we’re severely over-engineering in order to solve a problem that’s not important enough to justify the effort.

Cory
Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Martin Thomson-3
In reply to this post by Poul-Henning Kamp
On 5 August 2016 at 19:12, Poul-Henning Kamp <[hidden email]> wrote:
> Make the request contain the ID of a pre-shared-key.  If its on
> the list you get the full monty, if not, you only get a safe summary.

Or encrypt the response using TLS exporters.  If you are on the same
connection, then you will be able to extract the keys and decrypt.

Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Stefan Eissing
In reply to this post by Cory Benfield

> Am 05.08.2016 um 14:17 schrieb Cory Benfield <[hidden email]>:
>
>
>> On 5 Aug 2016, at 10:12, Poul-Henning Kamp <[hidden email]> wrote:
>>
>> Maybe it is one of those places where crypto could be useful:
>>
>> Make the request contain the ID of a pre-shared-key.  If its on
>> the list you get the full monty, if not, you only get a safe summary.
>
> So that kind of model certainly could work. At a certain point, though, one wonders if we’re severely over-engineering in order to solve a problem that’s not important enough to justify the effort.

The intend here is to help debugging when client X does not work with Server Y. I fail to see how pre-shared keys could facilitate this, given that the client could be a browser and the bug reporter not a developer.

I'd rather limit the amount of information it exposes than its usefulness.

-Stefan
Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Alex Rousskov
In reply to this post by Cory Benfield
On 08/05/2016 03:07 AM, Cory Benfield wrote:

> The longer term question is about how to deal with the fact that a
> misbehaving H2 connection could be the result of the H2 state in any of
> the hops on the connection. For example, if you have a connection that
> goes: client -> forward proxy A -> reverse proxy B -> origin server, and
> all those hops are H2, you really need to see H2 state in *all* of them
> to understand what the problem might be. However, the well-known URI
> doesn’t allow for that kind of debugging without requiring the awkward
> step of needing proxies to rewrite the response body to include their
> own data.

If you combine the well-known debugging URI with a Max-Forwards header,
then you may get pretty close to the desired "and here is my state too"
effect. It is not going to be "the state of each agent at the same
moment of time", but nothing is going to give you that precision anyway.

Alex.


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Cory Benfield

> On 5 Aug 2016, at 17:00, Alex Rousskov <[hidden email]> wrote:
>
> On 08/05/2016 03:07 AM, Cory Benfield wrote:
>
>> The longer term question is about how to deal with the fact that a
>> misbehaving H2 connection could be the result of the H2 state in any of
>> the hops on the connection. For example, if you have a connection that
>> goes: client -> forward proxy A -> reverse proxy B -> origin server, and
>> all those hops are H2, you really need to see H2 state in *all* of them
>> to understand what the problem might be. However, the well-known URI
>> doesn’t allow for that kind of debugging without requiring the awkward
>> step of needing proxies to rewrite the response body to include their
>> own data.
>
> If you combine the well-known debugging URI with a Max-Forwards header,
> then you may get pretty close to the desired "and here is my state too"
> effect. It is not going to be "the state of each agent at the same
> moment of time", but nothing is going to give you that precision anyway.

This was discussed, but was discarded in part because many proxies do not respect that header. Additionally, it’s only defined on OPTIONS requests.

Cory
Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Alex Rousskov
On 08/06/2016 10:33 AM, Cory Benfield wrote:

>
>> On 5 Aug 2016, at 17:00, Alex Rousskov <[hidden email]> wrote:
>>
>> On 08/05/2016 03:07 AM, Cory Benfield wrote:
>>
>>> The longer term question is about how to deal with the fact that a
>>> misbehaving H2 connection could be the result of the H2 state in any of
>>> the hops on the connection. For example, if you have a connection that
>>> goes: client -> forward proxy A -> reverse proxy B -> origin server, and
>>> all those hops are H2, you really need to see H2 state in *all* of them
>>> to understand what the problem might be. However, the well-known URI
>>> doesn’t allow for that kind of debugging without requiring the awkward
>>> step of needing proxies to rewrite the response body to include their
>>> own data.
>>
>> If you combine the well-known debugging URI with a Max-Forwards header,
>> then you may get pretty close to the desired "and here is my state too"
>> effect. It is not going to be "the state of each agent at the same
>> moment of time", but nothing is going to give you that precision anyway.

> This was discussed, but was discarded in part because many proxies do not respect that header.

I do not understand that reasoning: Surely those proxies that add
support for the new feature (debugging URI) can be required to support
Max-Forwards, at least in the context of that feature. Is it really
better to add Max-Forwards-2 or require response body adaptations?


> Additionally, it’s only defined on OPTIONS requests.

It is not prohibited for any other method. TRACE and OPTIONS are the two
methods where the protocol requires certain actions, but that does not
mean new features (like a debugging URI) cannot use it.

Alex.


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Cory Benfield

> On 8 Aug 2016, at 20:45, Alex Rousskov <[hidden email]> wrote:
>
> On 08/06/2016 10:33 AM, Cory Benfield wrote:
>
>> This was discussed, but was discarded in part because many proxies do not respect that header.
>
> I do not understand that reasoning: Surely those proxies that add
> support for the new feature (debugging URI) can be required to support
> Max-Forwards, at least in the context of that feature. Is it really
> better to add Max-Forwards-2 or require response body adaptations?

The problem is not those proxies that add support for the feature: the problem is those that *don’t*. For those that don’t add support, they blindly forward the request on, running the risk of information leakage and invalid/incorrect responses.

Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Alex Rousskov
On 08/09/2016 03:50 AM, Cory Benfield wrote:

> For those that don’t add support, they blindly forward the request
> on, running the risk of information leakage and invalid/incorrect
> responses.

I do not see how Max-Forwards unsupporting proxies can have a
significant negative effect on the problem you are trying to solve.
Obviously, you will not get their debugging state, but that is going to
happen no matter what -- there will always be proxies that do not
support your new feature. Why would Max-Forwards unsupporting proxies
produce invalid responses? They will just forward the response the next
hop gives them, and that response would be correct or incorrect
regardless of what they do.

AFAICT, Max-Forwards essentially lets you interrogate supporting hops.
Unless you change the protocol to require debugging support, nothing you
can do will let you interrogate unsupporting hops.

This overall problem feels very similar to traceroute -- it does not
always work and not all hops support ICMP TTLs, but it works well enough
in many cases to remain useful.

Alex.


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Cory Benfield

> On 9 Aug 2016, at 16:59, Alex Rousskov <[hidden email]> wrote:
>
> On 08/09/2016 03:50 AM, Cory Benfield wrote:
>
>> For those that don’t add support, they blindly forward the request
>> on, running the risk of information leakage and invalid/incorrect
>> responses.
>
> I do not see how Max-Forwards unsupporting proxies can have a
> significant negative effect on the problem you are trying to solve.
> Obviously, you will not get their debugging state, but that is going to
> happen no matter what -- there will always be proxies that do not
> support your new feature. Why would Max-Forwards unsupporting proxies
> produce invalid responses? They will just forward the response the next
> hop gives them, and that response would be correct or incorrect
> regardless of what they do.
>
> AFAICT, Max-Forwards essentially lets you interrogate supporting hops.
> Unless you change the protocol to require debugging support, nothing you
> can do will let you interrogate unsupporting hops.
>
> This overall problem feels very similar to traceroute -- it does not
> always work and not all hops support ICMP TTLs, but it works well enough
> in many cases to remain useful.
>

I think this summary is true if HPACK information is removed from the debugging output. So using Max-Forwards is conditional on not dumping HPACK. That may be an acceptable compromise.

Cory


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Alex Rousskov
On 08/10/2016 03:50 AM, Cory Benfield wrote:

> using Max-Forwards is conditional on not dumping
> HPACK. That may be an acceptable compromise.

What is wrong with receiving HPACK state from hop #(N+1) that has
allowed its HPACK state sharing, even if you actually asked to see HPACK
state of the unsupporting hop #N? I understand that #(N+1) may not be
very useful in some triage cases, but I am sure it will be useful in others.

The Via headers and/or equivalent will tell the client which hop
responded to the Max-Forwards:N debugging request (and, in most cases,
whether any unsupporting hops were skipped).

Alex.


Reply | Threaded
Open this post in threaded view
|

RE: H2 Implementation Debug State URI

Mike Bishop
The problem is that upstream HPACK context might well contain headers from requests that were made by clients other than you.  Leakage between connections is a bad thing.  You might be able to turn this on for in-depth debugging, but you'd *never* want that bit enabled on a live server.

-----Original Message-----
From: Alex Rousskov [mailto:[hidden email]]
Sent: Wednesday, August 10, 2016 9:17 AM
To: Cory Benfield <[hidden email]>
Cc: HTTP Working Group <[hidden email]>
Subject: Re: H2 Implementation Debug State URI

On 08/10/2016 03:50 AM, Cory Benfield wrote:

> using Max-Forwards is conditional on not dumping HPACK. That may be an
> acceptable compromise.

What is wrong with receiving HPACK state from hop #(N+1) that has allowed its HPACK state sharing, even if you actually asked to see HPACK state of the unsupporting hop #N? I understand that #(N+1) may not be very useful in some triage cases, but I am sure it will be useful in others.

The Via headers and/or equivalent will tell the client which hop responded to the Max-Forwards:N debugging request (and, in most cases, whether any unsupporting hops were skipped).

Alex.


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Poul-Henning Kamp
--------
In message <[hidden email]>, Mike Bishop writes:

If hop #N is a shared proxy, the HPACK state at hop #N+1 will disclose
info about other clients traffic.

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

Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Alex Rousskov
In reply to this post by Mike Bishop
On 08/10/2016 11:39 AM, Mike Bishop wrote:

> The problem is that upstream HPACK context might well contain headers
> from requests that were made by clients other than you.

It is not a problem under the stated precondition -- "hop that has
allowed its HPACK state sharing". Somebody has made a decision that such
sharing is OK in their specific environment, for that specific request, etc.

And it is easy to make HPACK sharing conditional so that the interface
can remain more open to less dangerous queries:

  # I know you are going to deny my request if I [implicitly] ask for
  # HPACK, so please note that I actually do not want to see it:
  uri = .well-known/h2/state?with-hpack=0


> Leakage
> between connections is a bad thing.  You might be able to turn this
> on for in-depth debugging, but you'd *never* want that bit enabled on
> a live server.

Yes, of course. I doubt any sane admin would enable this debugging by
default in a unprotected environment anyway, with or without HPACK. This
is a triage aid. Code like that is rarely of high quality and must be
protected.

These valid security concerns are not tied to the Max-Forwards mechanism
IMHO. This is like telling a carpenter to avoid the really heavy hammer
because somebody will get hurt if that hammer is misused.


Alex.


> -----Original Message-----
> From: Alex Rousskov [mailto:[hidden email]]
> Sent: Wednesday, August 10, 2016 9:17 AM
> To: Cory Benfield <[hidden email]>
> Cc: HTTP Working Group <[hidden email]>
> Subject: Re: H2 Implementation Debug State URI
>
> On 08/10/2016 03:50 AM, Cory Benfield wrote:
>
>> using Max-Forwards is conditional on not dumping HPACK. That may be an
>> acceptable compromise.
>
> What is wrong with receiving HPACK state from hop #(N+1) that has allowed its HPACK state sharing, even if you actually asked to see HPACK state of the unsupporting hop #N? I understand that #(N+1) may not be very useful in some triage cases, but I am sure it will be useful in others.
>
> The Via headers and/or equivalent will tell the client which hop responded to the Max-Forwards:N debugging request (and, in most cases, whether any unsupporting hops were skipped).
>
> Alex.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: H2 Implementation Debug State URI

Cory Benfield

> On 10 Aug 2016, at 21:11, Alex Rousskov <[hidden email]> wrote:
>
>
> And it is easy to make HPACK sharing conditional so that the interface
> can remain more open to less dangerous queries:
>
>  # I know you are going to deny my request if I [implicitly] ask for
>  # HPACK, so please note that I actually do not want to see it:
>  uri = .well-known/h2/state?with-hpack=0

So draft-01 now explicitly says that the HPACK state dictionary should almost always be omitted. This may allow us to reconsider the Max-Forwards notion.

Cory