Allow for hash/versions in the middle of the path

[pmeenan]

A lot of build systems produce static resources that are prefixed by a build number and that doesn't work well with a prefix-only match. i.e. /app/123/main.js

We could allow for more flexible path matching with some form of wildcard support but that will complicate the "most-specific" matching logic and the ownership protections.

Using a # for a wildcard (since it is already reserved as a client-side separator) we could allow for exact matching by default, prefix matching with a # at the end or wildcard matching.

Some open questions:

• How would the specificity be ranked if there are multiple matches? Overall match string length feels like it should be safe but would it lead to unexpected results?
• Does this open up ownership/scope issues for shared-host environments? Maybe, at a minimum, require the first path component to be specified when using wildcards if the dictionary is not served from the root path?
• Does it need to support multiple wildcards? At a minimum, allow for 1 in the middle and one at the end?

[yoavweiss]

I wonder if this has some precedents in the platform. (In terms of a DSL that enables such strict expansion)

If we don't do this:

• Resources that don't fall into a strict prefix bucket would not be able to use delta compression (might be interesting to understand what %age of resources that may be).
• Site operators that would want to move such resources to URL patterns that enable delta compression would need to go through a migration process, cache loses, etc

So assuming this impacts a lot of resources, I agree that making adoption easier would be valuable.

• Does this open up ownership/scope issues for shared-host environments? Maybe, at a minimum, require the first path component to be specified when using wildcards if the dictionary is not served from the root path?

Would be interesting to look at real-world examples and see the best tradeoff between current URL patterns and stable path ownership proof

[pmeenan]

I should be able to pull some stats from the HTTP Archive from month to month and at least get some stats for similar JS/CSS URLs, when they vary where the variation is.

Even in my spot test looking at HTML and static JS it was already pretty prevalent.

The ownership concerns may be over-blown as well. With service workers, accidentally installing one at global scope could break other parts of the site and cause all sorts of issues. With the dictionaries, crossing ownership boundaries on a given origin would just disable the compression if the dictionary wasn't available across paths (and it would advertise the dictionary hash that had taken over).