search

WICG / compression-dictionary-transport

Other
92 stars 8 forks source link

Abbreviated structured field dictionary keys #27

Closed annevk closed 1 year ago

annevk commented 1 year ago

Why is it p and not path? Same for the other fields.

cc @mnot

pmeenan commented 1 year ago

Mostly to keep things short. We did the same with extensible HTTP priorities using u for urgency and i for incremental.

I think we're fine either way but the HTTP working group usually seems to skew towards brevity.

annevk commented 1 year ago

We didn't do this for https://w3c.github.io/reporting/#header. Seems unfortunate we're not consistent here.

If this is going for TAG review, could you ask about this? It seems https://w3ctag.github.io/design-principles/#naming-is-hard is in need of an update.

pmeenan commented 1 year ago

Looks like the reporting header is a flat dictionary with no pre-defined keys (each key is a "name" for the given endpoint).

We're still pre-experiment so it's a good time to make changes. I'll default to long prefixes as the starting point and see if shortening is necessary. We're already using base-16 hash strings instead of base-64 for convenience over brevity.

mnot commented 1 year ago

Brevity, yes, but that's usually regarding ReallyPointlesslyLongHeaderNames. I don't think you'd get much pushback on path vs p (although I agree someone will say something).

pmeenan commented 1 year ago

While we're looking at the naming, would match be clearer than path to the extent that what is being specified is the path-matching rule to be used for future requests?