You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation: every page on sites, where Cookie Notice plugin is active, has two variants: one with cookie notice banner and one without it. This way, only part of visitors can be served from cache: either those who haven't accepted cookie policy yet or those who did.
Idea: store alternative page variants (HTML responses) in directories with #variant-name appended to the directory name. This should be safe, as # will never be part of request URI (and thus default directory name), but is a perfectly legal character in directory name under both Unix/Linux and Windows.
The text was updated successfully, but these errors were encountered:
Note: The feature would require URI to directory relationship to change from 1:1 to 1:N (one URI can be cached in multiple directories). Not a big problem now, but should be considered, because #4 might be implemented one day and cache API supports deletion of single URI already.
The final implementation did not include variant name in directory names, but in file names. It seemed more clean and was quite straight-forward to implement as the implementation aligns well with the handling of gzipped variants. Also, the 1:1 relationship between request URI and directory is retained.
chesio
changed the title
Implement page variants handling
Implement request variants handling
Sep 20, 2018
Motivation: every page on sites, where Cookie Notice plugin is active, has two variants: one with cookie notice banner and one without it. This way, only part of visitors can be served from cache: either those who haven't accepted cookie policy yet or those who did.
Idea: store alternative page variants (HTML responses) in directories with
#variant-name
appended to the directory name. This should be safe, as#
will never be part of request URI (and thus default directory name), but is a perfectly legal character in directory name under both Unix/Linux and Windows.The text was updated successfully, but these errors were encountered: