"Optimize" like in "call it less" or like in "make it faster"? If uglier code is fine, unrolling the loop gives a nice boost EDIT: yeah, need to benchmark better.

"Optimize" like in "call it less" or like in "make it faster"?

Either/both?

How long are typical inputs to constantTimeStringCompare?
For long strings pseudo-simd can help:
x:= a[i+0] | a[1] << 8 .. //should compile to single bound check + machine-word sizedload
y:= b[i+0]...
z |= x^y
i+=8
However code will be different for little and big endian, and won't work on architectures requiring aligned loads. It will also be quite ugly. Alternatively unsafe (or even asm) can be used.
In any case representative benchmarks are needed as a first step.

Inputs are HTTP header values, so typically less than 100 bytes. (The longest would probably be some random UUID/hex-looking session identifier.)

CL https://golang.org/cl/37329 mentions this issue.

@tombergan, are you able to share a histogram of HTTP header value sizes from the Flywheel data?

I tried looking at https://telemetry.mozilla.org/ too but don't see it.

I'm not sure why constant time string comparison is needed in the first place. RFC 7541 does not mention a need for this AFAICT. I couldn't find any reported vulnerabilities after a quick search. It seems like staticTable could be implemented as a map rather than an array. I looked at the source code for two other HTTP2 implementations. Neither appears to use constant-time string comparisons:

• nghttp2
• Chrome

/cc @tatsuhiro-t who originally wrote the code, thoughts?

There was a statement regarding prevention of timing attacks, but it was removed.
See httpwg/http2-spec@f4ec4e3

Thanks for digging that up. In that case, I think it's safe to remove the constant-time string comparison entirely.

SGTM. Sent you a CL.

I think it was removed because Never Indexed has been introduced for the sensitive header fields.

CL https://golang.org/cl/37394 mentions this issue.