OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [oslc-core] Choice for Configuration context request headder (was: [oslc-core] Agenda for 15 May 2014)


I was exploring your statement in [1] that using Link headers has a negative effect on cacheability versus a new specific header, because Vary's "units" are header names, not the more granular "header-name=Link + link-relation-name=config-context" test that we'd prefer in a perfect world.

Today, the usage of Link headers on *requests* is rare, so (today) if effectively the only usage of Link request-headers is for configuration context, the lack of granularity in the Vary units has no practical negative effect.  It introduces no new problems (today).

The rest was a thought exercise to poke at what would happen if "today"'s assumptions were suddenly invalidated - if a new unrelated usage for Link request headers came about in widespread usage tomorrow, a usage that on its own did not affect cacheability.  In that case, would the config-context usage (and consequent Vary restrictions on cacheability) create or compound any problems?  Remember that what caches do, in effect, is pattern-match incoming requests against earlier ones, and (if a match is found and cache controls allow it, etc.) use the cached response.  So if the pattern involves all Link headers (as it would whenever the resource requires a config context), does that cast too wide a net?

To take a concrete artificial example, let's say someone else decides that supplying Link rel="tag" [HTML5] and a target that varies for each request (like I said, artificial - this variance makes it worst case for caching).  If you prefer something incrementally more reasonable, use rel=client's request time or =client's request log entry (nothing in [2] forces Link target IRIs to be dereferencable, FYI - could be URNs etc).

What seems to be true is that, in the case of a config-context-qualified resource, whose responses will always include a Vary: Link header, effectively become uncacheable (because the Link rel=tag content is different for each request).  That risk, since it's degree of remoteness is a matter of opinion, might concern people enough to lean toward your "new header" alternative which lacks this downside but otherwise functions similarly (Link's syntax allows for the conveyance of target attributes ... attributes describing the resource identified by the target IRI ... that I don't think your proposal allows for, but if you don't need them "so what/that's a feechur".  The question might reduce to whether or not your alternative should allow for extensions in its BNF - we haven't really gotten to that level of detail in yours.)


[1] https://lists.oasis-open.org/archives/oslc-core/201405/msg00024.html

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]