- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 12 Jun 2012 12:19:40 +1200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: <ietf-http-wg@w3.org>
On 12.06.2012 01:20, Julian Reschke wrote: > On 2012-06-11 15:04, Amos Jeffries wrote: >> ... >> * flag parameters can't exactly contradict, so dropping/merging >> duplicates and treating as one flag would seem okay. (only-if-cached >> must-revalidate, proxy-ravalidate, no-cache, no-store, no-transform, >> etc) > > "public" vs "private"? Okay. Nasty case there. "public" is specifically linked to the auth systems though isn't it? Can we safely assume that "private" on auth responses is invalid and that "public" was intended to override it? on non-auth responses "public" would seem to be the redundant state, and "private" assumed to be the desired behaviour? > >> * time-delta parameters (max-age, s-maxage, etc) being conservative >> and >> dropping the larger or equal of the two seems the right handling. > > Yes, we could say that. > >> * list of tokens ... maybe combine? it is possible one proxy adds >> no-cache="Foo" and another adds no-cache="Bar" and they both hit >> some >> downstream cache which needs to handle both Foo and Bar properly. >> Yes the right thing to do woudl have been no-cache="Foo Bar". But >> what if that is not done? > > Right now we allow > > no-cache="Foo, Bar" > > Should > > no-cache="Foo", no-cache="Bar" > > be equivalent? (That would be similar with the use of list syntax in > header fields) I think so, yes. Amos
Received on Tuesday, 12 June 2012 00:20:06 UTC