Re: Transient content negotiation

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Larry Masinter: "Re: Transient content negotiation"
• Previous message: Dave Kristol: "new cookie I-D submitted"
• In reply to: Graham Klyne: "Transient content negotiation"
• Next in thread: Larry Masinter: "Re: Transient content negotiation"

Graham Klyne:
>
[...]
>This suggests to me that it might be desirable to tag negotiable features
>as 'transient' as a warning to intermediate systems to avoid caching these
>(negotiable feature) values in an attempt to 'optimize' future
>negotiations.

Here is how caching of negotiation metadata is handled in HTTP
transparent content negotiation:

 - information about the feature set of the browser, if it is sent
   over the wire at all, is never cached (at least not under HTTP/1.1,
   a future protocol extension may provide sticky header or
   dictionary mechanisms which could cache such information for a
   short while).

 - information about the (features of the) content available at the
   server end can be cached, and the whole package (the complete
   variant list) can be assigned a caching lifetime according to the
   normal HTTP/1.1 max-age model.  Conditional GETs can refresh the
   package if it is becomes stale.

So there is no cache control at the level of individual features.  I
don't know whether such fine-grained caching would be useful in fax
applications.

>GK.

Koen.

• Next message: Larry Masinter: "Re: Transient content negotiation"
• Previous message: Dave Kristol: "new cookie I-D submitted"
• In reply to: Graham Klyne: "Transient content negotiation"
• Next in thread: Larry Masinter: "Re: Transient content negotiation"