Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cookies #549

Open
mnot opened this issue Apr 2, 2018 · 6 comments
Open

Cookies #549

mnot opened this issue Apr 2, 2018 · 6 comments
Labels

Comments

@mnot
Copy link
Member

mnot commented Apr 2, 2018

Would an algorithm to key the cache on a cookie by name work?

(moved from mnot/I-D)

@mnot
Copy link
Member Author

mnot commented Nov 13, 2018

I think the basic use case here is "a request with a cookie named X whose value matches Y can use this response," where X is nominated in the Variants header, and Y is matched in the request (and Variant-Key).

E.g.,

Variants: cookie; foo
Variant-Key: 1

Could be used to match a request with:

Cookie: foo=1

TBD:

  • Is that enough? Other use cases?
  • See how the actual algorithm / serialisation works
  • Handle cases where the cookie isn't present
  • How does it work with multiple cookies? Combining with other headers?

@jyasskin
Copy link
Contributor

That looks like a different meaning for Variants than the spec defines. Specifically, the ABNFs are:

Variants        = 1#variant-item
variant-item    = field-name *( OWS ";" OWS available-value )
available-value = ...
Variant-Key      = 1#available-values
available-values = available-value *( ";" available-value )

Your suggestion for cookies has Variants formatted like field-name *(";" subfield-name) instead. That'll lead to the result of https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#cache never matching the normalized Variant-Keys value, and the cache will never return one of these responses.

If you want to select particular cookies, I think you need to mess with the field-name part of the Variants header, perhaps by delimiting subfields by a non-tchar.

@mnot
Copy link
Member Author

mnot commented Feb 6, 2019

Yes, that was from a previous syntax - thanks for the reminder.

mnot added a commit that referenced this issue Aug 30, 2019
@mnot
Copy link
Member Author

mnot commented Aug 30, 2019

See proposal roughed in above; @jyasskin I'm curious to know if this seems sensible to you.

@essen
Copy link
Contributor

essen commented Nov 25, 2019

The current text for cookies does not work with structured headers, more specifically this part:

Note that if more than one cookie-name serves as a cache key,
they’ll need to be listed in separate Variants members, like this:

Variants: Cookie=(user_priority), Cookie=(user_region)
Variant-Key: (gold europe)
Vary: Cookie

The problem is that in https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-14#section-3.2 it says:

There can be zero or more members, and their names are required to be
unique within the scope of the dictionary they occur within.

So unless I'm mistaken we cannot have cookie twice. And you can't really put the cookie name as the member name due to syntax restrictions (lowercase plus a small set of allowed characters). Maybe a special variant header for cookies would work better?

@essen
Copy link
Contributor

essen commented Nov 25, 2019

This one is probably wrong as well because 0 is not a string or token, it's an integer. It probably should be "0".

   Variants: Cookie=(logged_in)
   Variant-Key: (0)
   Vary: Cookie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants