0

in the RFC for hpack, it says this...

The dynamic table can contain duplicate entries (i.e., entries with the same name and same value). Therefore, duplicate entries MUST NOT be treated as an error by a decoder

in the table, since the static and dynamic table are one (via index address space in RFC), does this mean if i have the header: headername: headervalue in index 75, then i encounter it in a new request, i should also add it to the dynamic table although its already at index 75? If so, which one would i reference, index 75 or the newest index? Then, what happens if i encounter a header that has the same name but with each request has a new value, can i keep the header name that never changes in the dynamic table then use that index to decode the header name only?

user18043747
  • 1
  • 1
  • 4

1 Answers1

0

does this mean if i have the header: headername: headervalue in index 75, then i encounter it in a new request, i should also add it to the dynamic table although its already at index 75?

Ideally you shouldn’t. It’s a waste of space to do that. But you CAN do that if you want to and have a good reason too.

If so, which one would i reference, index 75 or the newest index?

You can use either one. Each is equally valid. And in fact web browsers sometimes implement this differently as illustrated in this question: Weird HTTP/2 HPACK encoding in Firefox

Then, what happens if i encounter a header that has the same name but with each request has a new value, can i keep the header name that never changes in the dynamic table then use that index to decode the header name only?

Yes you could. Ideally such fields would be sent with Literal Header Field without Indexing (or the similar Literal Header Field Never Indexed) syntax to prevent them filling up the dynamic table with useless, single-use values. However, that would also mean the header name would also not be indexed so you couldn’t look just that up as you hoped.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • > but you CAN do that if you want.... How does this work? Because if the client doesn't do it and the server DOES then since the client doesn't the index could possibly be evicted from the table but since the server adds it everytime it's encountered, its present, thus allowing the server to send that index its at? – user18043747 Apr 04 '22 at 00:20
  • The sender encodes the header using one of the methods discussed here: https://httpwg.org/specs/rfc7541.html#literal.header.representation. The sender tells the receiver how it wants the header encoded. So for a browser-server interaction, the browser decides how the request headers are encoded (as it sends those) and the server decides how the response headers are encoded (as it sends those). – Barry Pollard Apr 04 '22 at 06:53