Re: [w3ctag/design-reviews] `sec-metadata` (#280)

Thanks, @mnot!

> [many reasons not to encode data in a bitfield]

I generally agree. The proposal was somewhat _ad absurdum_ in nature. I generally agree with @arturjanc's [comment](https://twitter.com/arturjanc/status/1062642821906210816) that "We should likely be making it easier for developers to use security mechanisms. Requiring application-level decompression is awkward and a barrier to entry." I would prefer human-readable headers when possible.

> IOW, don't over-optimise for header size.

This sounds like good advice.

> The upshot here is that HTTP header compression is heavily optimized for header values that don't have a lot of variance on a connection. Don't fight it :)

This sounds like a reasonable argument in favor of splitting the header into a million little shards. Thank you for the primer on header compression (whose constraints I think I still don't really understand); I appreciate the review.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/280#issuecomment-438951529