There's been a lot of interest in a finer-grained Vary function (i.e., something that lets you specify the cache key on something more flexible than just whole headers). We're working a a spec in the background, but of course caches will need to support it...
Cheers, On 05/09/2011, at 3:43 PM, Bryan Taylor wrote: > It _would_ be useful to have Vary pick out a link by its rel, even on a > request. Maybe the rel="" part should've been considered part of the > header: > Link;rel="Keystone-token" : blah > > Or maybe Vary should support matching on header values: > Vary: Link:*;rel="keystone-token" > > > On 9/4/11 9:51 PM, "Mark Nottingham" <m...@mnot.net> wrote: > >> Good point; Link makes more sense on a response. >> >> Cheers, >> >> >> On 05/09/2011, at 12:49 PM, Bryan Taylor wrote: >> >>> Hmmm, I'm thinking more about this. Would using the Link: header break >>> the >>> ability to use the Vary header? I can't Vary on a Link header based on >>> it's rel attribute. >>> >>> So maybe Keystone-Token is the way to go. I could see intermediaries >>> doing >>> the token resolution and adding headers like Keystone-User and >>> Keystone-Tenant which could also be used in Vary Headers. >>> >>> >>> On 9/4/11 8:06 PM, "Bryan Taylor" <btay...@rackspace.com> wrote: >>> >>>> Love it. >>>> >>>> >>>> Link: >>>> <https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c>; >>>> rel="keystone-token" >>>> >>>> >>>> Fixed: s/tenants/tokens/ (my bad). >>>> >>>> >>>> On 9/4/11 7:40 PM, "Mark Nottingham" <m...@mnot.net> wrote: >>>> >>>>> Still getting up to speed on the finer points of keystone, but makes >>>>> sense to me. >>>>> >>>>> Is X-Auth-Token keystone-specific? If so, calling it something like >>>>> "Keystone-Token" would be better (X- is falling out of favour; see >>>>> <http://tools.ietf.org/html/draft-saintandre-xdash-03>). That'd also >>>>> avoid problems with people expecting the other format. >>>>> >>>>> Finally, if you're going to make it a URI, best to enclose it in >>>>> quotes - >>>>> URIs can contain commas, which can be a delimiter in HTTP headers >>>>> (especially if multiple tokens might be allowed). >>>>> >>>>> E.g., >>>>> Keystone-Token: >>>>> "https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c"; >>>>> >>>>> Cheers, >>>>> >>>>> P.S. If these are going to show up in other contexts, it *might* make >>>>> sense to define keystone-token as a link relation >>>>> <http://tools.ietf.org/html/rfc5988>, giving you: >>>>> >>>>> Link: >>>>> >>>>> <https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c>; >>>>> rel="keystone-token" >>>>> >>>>> >>>>> On 04/09/2011, at 2:39 AM, Bryan Taylor wrote: >>>>> >>>>>> I propose identifying tokens by their full keystone URI within >>>>>> X-Auth-Token header. EG: instead of >>>>>> X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c >>>>>> we would do >>>>>> X-Auth-Token: >>>>>> https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c >>>>>> >>>>>> This has the advantage of allowing federated tokens, and allowing >>>>>> APIs >>>>>> and even resources to use the auth server in access decisions. A >>>>>> given >>>>>> service would maintain a whitelists of keystone servers. The service >>>>>> would take the request, get the token, and verify that the host of >>>>>> the >>>>>> token URI matches one from the appropriate whitelist, and then do a >>>>>> GET >>>>>> on the token per the keystone API. >>>>>> >>>>>> For example, consider rackspace. We might have 3 keystone servers: >>>>>> region1.customer.keystone >>>>>> region2.customer.keystone >>>>>> employee.keystone >>>>>> >>>>>> The management API might set it's whitelist to {employee.keystone}, >>>>>> while the public APIs could whitelist all three, or maybe just the >>>>>> first >>>>>> two. >>>>>> >>>>>> This creates three ways to do remote federation. >>>>>> 1) Each service could simply add remote keystone APIs to its >>>>>> whitelists. >>>>>> 2) A whitelisted keystone server return REDIRECT, which services >>>>>> implicitly trust >>>>>> 3) A whitelisted keystone server could forward the request directly >>>>>> >>>>>> Items 2 and 3 might be facilitated by adding an "@host" string to the >>>>>> end of the token to allow the keystone implementation to map the >>>>>> token >>>>>> to its source. Eg: if the service receives a token that is not from a >>>>>> whitelisted client, such as >>>>>> >>>>>> >>>>>> https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a937 >>>>>> 0c >>>>>> >>>>>> then it mutate the token to hit a trusted keystone implementation: >>>>>> >>>>>> >>>>>> https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@k >>>>>> ey >>>>>> s >>>>>> tone.utexas.edu >>>>>> >>>>>> The keystone.server implementation could verify the trust >>>>>> relationship >>>>>> with keystone.utexas.edu and redirect or forward back to the >>>>>> original. >>>>>> This would allow remote federations to be controlled by the trusted >>>>>> keystone servers in a way that a client can leverage with no special >>>>>> knowledge they just auth against their normal keystone servers and >>>>>> proceed. >>>>>> This email may include confidential information. If you received it >>>>>> in >>>>>> error, please delete it. >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~openstack >>>>>> Post to : openstack@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>>>> >>>> >>>> This email may include confidential information. If you received it in >>>> error, please delete it. >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> >>> This email may include confidential information. If you received it in >>> error, please delete it. >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> > > This email may include confidential information. If you received it in error, > please delete it. > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
