Consider dropping default boolean headers.

[mikewest]

Requests will generally contain Sec-Fetch-User: ?F, which doesn't provide much value. Perhaps we can save some bandwidth by only sending boolean headers when they're interesting?

(As discussed in #18 (comment))

[mikewest]

@arturjanc, @yoavweiss: If we omit the header rather than sending an explicit ?F, does Vary: Sec-Fetch-User, well, vary?

[yoavweiss]

My reading of RFC 7234 is that a request with a non-empty Sec-Fetch-User will vary from a request with an empty or non-existant Sec-Fetch-User.

A quick glance at the relevant Chromium code also suggests that it will vary, as it seems to calculate the MD5 hash of the request value, even if that value is the empty string.

[arturjanc]

I did some quick testing and my observations agree with @yoavweiss's comment above: see the Vary: width tests at https://www.arturjanc.com/vary-check/index.html

Basically, when the server sends a Vary with a header name that is present in one request but not another, the browser doesn't return the cached result. I believe that's what we want.

[mikewest]

I'm dropping Sec-Fetch-User when it's false. If that turns out to be a terrible idea, we can add it back in later. :)