Subject: Header addition with HTTP 2.0

From: Vimala Tadepalli <[email-masked]>
Date: Mon, 30 Mar 2015 14:34:58 -0700

Hi,

I work on a firewall, where we need to add a header to the client request
going to the server.

Topology is

Client -------> Firewall -------> Servers

Ex: Suppose a request is going to youtube, a new header "
X-YouTube-Edu-Filter" has to be added to the request.

In HTTP 1.0/1.1, this is feasible
I tried with SPDY as well and Server did accept the request and redirected
accordingly.

In HTTP 2.0, can i do this?
If a header is added at firewall, client and server dynamic tables might go
out of sync. Will it cause any issues?

Any suggestion is greatly appreciated.

Thanks
Vimala

---

From: Roberto Peon <[email-masked]>
Date: Mon, 30 Mar 2015 14:53:22 -0700

HTTP2 is semantically the same.
It'd depend on the implementation of the firewall, rather than anything
else.

-=R

On Mon, Mar 30, 2015 at 2:34 PM, Vimala Tadepalli <[email-masked]> wrote:

> If a header is added at firewall, client and server dynamic tables might
> go out of sync. Will it cause any issues?
>

---

From: Vimala Tadepalli <[email-masked]>
Date: Mon, 30 Mar 2015 16:31:55 -0700

I should be using "Literal Header Field never Indexed" to add a new header?
Thanks
Vimala

On Mon, Mar 30, 2015 at 2:53 PM, Roberto Peon <[email-masked]> wrote:

>> I tried with SPDY as well and Server did accept the request and
>> redirected accordingly.
>>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 30 Mar 2015 17:32:21 -0700

Most HTTP2 implementations will likely be over TLS, so you'll find it
difficult to insert anything.
If you have plaintext access, you can do anything, and yes, using that
operation would make the most sense.

imho, such behavior should be avoided, if possible.
-=R

On Mon, Mar 30, 2015 at 4:31 PM, Vimala Tadepalli <[email-masked]> wrote:

>>> I work on a firewall, where we need to add a header to the client
>>> request going to the server.
>>>
>>> Topology is
>>>

---

From: Vimala Tadepalli <[email-masked]>
Date: Mon, 30 Mar 2015 20:02:28 -0700

Hi
Ssl is not a problem since our firewall acts as a middleman, so we can see
the text inside. This header modification is basically to support this
feature

https://support.google.com/youtube/answer/2695317?hl=en

I am not sure if there is any better way to support it.

Thanks
Vimala

>> I should be using "
>> Literal Header Field never Indexed" to add a new header?
>>
>> Thanks
>> Vimala
else.
>>>> Ex: Suppose a request is going to youtube, a new header
"X-YouTube-Edu-Filter" has to be added to the request.
redirected accordingly.
>>>> If a header is added at firewall, client and server dynamic tables
might go out of sync. Will it cause any issues?

---

From: Vimala Tadepalli <[email-masked]>
Date: Tue, 31 Mar 2015 13:03:01 -0700

All this effort is to redirect youtube.com requests to youtube.com/education
.
Is there any other way to redirect other than adding the header?

Thanks
Vimala

On Tue, Mar 31, 2015 at 12:59 PM, Bence Béky <[email-masked]> wrote:

> Hi,
>
> On Mon, Mar 30, 2015 at 5:34 PM, Vimala Tadepalli <[email-masked]>
> wrote:
> Good question.  My understanding is that the firewall is supposed to
> re-encode the header.  That is, it should maintain a dynamic table on
> its connection with the client that stays in sync with that of the
> client, decode the header block using this dynamic table, and
> re-encode it towards the server using a context that is in sync with
> the server.
>
> Cheers,
>
> Bence
>

---

From: Bence Béky <[email-masked]>
Date: Tue, 31 Mar 2015 16:04:39 -0400

[re-posting from the right address]

Hi,

Cheers,

Bence

---

From: Bence Béky <[email-masked]>
Date: Tue, 31 Mar 2015 16:06:24 -0400

Hi,

On Tue, Mar 31, 2015 at 4:03 PM, Vimala Tadepalli <[email-masked]> wrote:
> All this effort is to redirect youtube.com requests to
> youtube.com/education.

Seems like you can rewrite outgoing URLs instead, see section 2B of
the document you linked:
https://support.google.com/youtube/answer/2695317?hl=en.

Cheers,

Bence

---

From: Vimala Tadepalli <[email-masked]>
Date: Tue, 31 Mar 2015 13:14:52 -0700

Yes. I am aware of that. With HTTP 2.0 even URL is inside the headers frame.
Basically it would be similar to adding a new header.
We have to decode with one context and re-encode with another context, so
that dynamic tables would not be messed up.

---

From: Bence Béky <[email-masked]>
Date: Tue, 31 Mar 2015 16:17:39 -0400

> Basically it would be similar to adding a new header.

Sorry, I forgot about that.  In that case, you are right, there is no
way to avoid re-encoding the header.

---

From: Bence Béky <[email-masked]>
Date: Tue, 31 Mar 2015 20:00:02 +0000

Hi,

Cheers,

Bence

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 15:19:40 -0700

> way to avoid re-encoding the header.

There is: if you aren't doing anything more than adding a header
field, as long as you choose a literal representation and you also
pass through all messages that relate to the header table (max size,
everything) verbatim, you can shim this in.  You won't learn much in
the process though unless you maintain your own table because you
won't be able to decode header fields without the header table.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Apr 2015 16:56:58 +1300

On 1/04/2015 11:19 a.m., Martin Thomson wrote:
> On 31 March 2015 at 13:17, Bence Béky wrote:

And to carify for the record by "shim it in" you mean append/insert the
new header to the existing HEADERS payload using a "Literal Header Field
without Indexing" and incrementing the HEADERS length field to account
for the new bytes, right?

With of course the complex logical adjustments for HEADERS padding,
frame max-length and CONTINUATION frames.

PS. "Literal Header Field never Indexed" is also an option, but
restricting what recipient proxies can do to relay the HEADERS is not
always desired. Either of the not-Indexed encodings will work.

Amos