Sorry, I don't really understand the problem so I don't understand how your proposal to modify internal code helps.

Are you asking for new API, or is this purely an optimization request?

Do you have a self-contained minimal example program to demonstrate the issue?

/cc @tombergan

@bradfitz Sorry for my poor description.
I mean server will always return server-time(mw-st) and current-request-rt (mw-rt)in http2 header which will write into hpack.HeaderFiled like

for k, v := range md {
   for _, entry := range v {
         // mw-st = 1496630402035
         // mw-rt = 10(ms)
        transport.hEnc.WriteField(hpack.HeaderField{Name: k, Value: entry})
  }
}

both name (mw-st) and value (1496630402035) will add into t. byName and t.byNameValue when sensitive is false default

name will insert into

t.byName[f.Name] = id

and value which change per response also indexing

t.byNameValue[pairNameValue{f.Name, f.Value}] = id

which make t.byNameValue grow and []HeaderField evict by time goes

Is it possiable for new API seperated t.byName and t.byNameValue insert-action apart ,to help entry which has static name and dynamic value only insert t.byName and discard pairNameValue{f.Name, f.Value} to slowdown map grow , improving hit rate for other name-value indexing?

There were changes to the hpack code recently, I think affecting the code you're talking about. Can you try Go tip? Or using golang.org/x/net/http2 directly, instead of the version bundled into std?

@bradfitz I use x/net/http2 directly as vendor already since I customized the gRPC and don't want to change x/net/http2 lib behavior privately : p

Please give us a complete Go program demonstrating the problem from a user's perspective, without referencing hpack internals.

I think I mostly understand the request:

HPACK has a dynamic table that is a list of "header fields", where each header field is a name/value pair. Suppose we have the following sequence of header fields:

1. mw-st: 1
2. mw-st: 2
3. mw-st: 2

In HPACK, the first field could be encoded as in Figure 7, the second field could use an index to the first field's name as in Figure 6, and the third field could use an index to the second field's name/value pair as in Figure 5 (https://tools.ietf.org/html/rfc7541#section-6.2.1). Go's HPACK library already does this.

I believe @Zeymo is asking for an additional feature: In the above case, we know that duplicate mw-st values are impossible -- specifically, case 3 is impossible -- so there's no reason to add mw-st: 1 or mw-st: 2 into the byNameValue mapping. No future name/value pair will match either of those fields. This would save memory and GC time by not allocating useless pairNameValue structs. (How much memory and GC time, I have no idea.)

In any case, this would be simple to support if we wanted to: add a boolean field IndexNameOnly to hpack.HeaderField. When true, the field will be added to byName but not byNameValue.

A shorter-term option is to set HeaderField.Sensitive = true. This won't compress header field names, but if the names are actually short (like mw-st), you're not getting much from header name compression anyway.

@tombergan absolutely right. Although filed like mw-st , mw-trace-id or mw-cookie actually short which duplicate values are impossible ,but filed like these at least 5~8 are always return in HeaderFrame per response for app full chain metrics. and also for request HeaderFrame in same scenario
now , I already set senstive=true for shorter-term

What about adding the ability to control which headers are set a Sensitive at the http2.Transport level? We could expose a new parameter as follow:

type Transport struct {
   ...
    SensitiveHeader func(h hpack.HeaderField) bool
}

This function would be called byClientConn.writeHeader determine if the Sensitive field should be set.

This would give the opportunity to define which header values should be indexed or not. Always returning true, would disable name/value indexing altogether as requested by @Zeymo.

Typical use-case for this is when the building a gateway that can multiplex requests from different users to the same backend connection. In this context, unique per-user headers like cookie can thrash the table to the extent that indexing becomes counter-productive.

Change https://golang.org/cl/154917 mentions this issue: http2: add hpack header options control on Transport