[Openid-specs-ab] Form Post Response Mode example has 'Pragma: no-cache'

Brian Campbell bcampbell at pingidentity.com
Mon Mar 2 22:13:06 UTC 2015


+1 and echo what Justin said

On Mon, Mar 2, 2015 at 2:56 PM, Justin Richer <jricher at mit.edu> wrote:

> +1, this is a good balance between correctness and pragmatism.
>
>  — Justin
>
>
> On Mar 2, 2015, at 4:54 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>  I think this is where we are:
>
>
>
> Add this normative text:
>
>
>
> "Because the Authorization Response is intended to be used only once, the
> Authorization Server MUST instruct the User Agent (and any intermediaries)
> not to store or reuse the content of the response."
>
>
>
> Use these directives in the example:
>
>
>
> Cache-Control: no-cache, no-store
>
> Pragma: no-cache
>
>
>
> Let’s close on the text to use during the call in just over an hour.  Talk
> to you soon…
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Brian Campbell [mailto:bcampbell at pingidentity.com
> <bcampbell at pingidentity.com>]
> *Sent:* Monday, March 02, 2015 1:46 PM
> *To:* Mike Jones
> *Cc:* John Bradley; Breno de Medeiros; <openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example has
> 'Pragma: no-cache'
>
>
>
> Though I still prefer that any normative text be somewhat general and
> avoid mandating specif headers or values.  There was one such (rough)
> proposal for text earlier in this thread.
>
>
>
> On Mon, Mar 2, 2015 at 2:29 PM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
> Yeah, I guess I was hoping that some of the messiness of the internet was
> old enough that it didn't have to be in new specs. But that was likely
> silly.
>
> If we go with Mike's proposal, the example would have a "no-cache"
> directive added to the "Cache-Control" response header. And the "Pragma:
> no-cache" stays. *sigh*
>
>
>
>
>
> On Sat, Feb 28, 2015 at 7:00 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> In the example, I propose that we go with the directives that Google uses
> in practice.  At least we have the weight of their data and usage behind
> this choice.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] *On
> Behalf Of *John Bradley
> *Sent:* Friday, February 27, 2015 2:48 PM
> *To:* Breno de Medeiros
> *Cc:* <openid-specs-ab at lists.openid.net>
>
>
> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example has
> 'Pragma: no-cache'
>
>
>
> Yes that was what I was trying to say on the call.   From my recollection
> of working with caches you still need to send the HTTP 1.0 Pragma: no-cache
> as some will ignore the HTTP 1.1.
>
>
>
> There are cable and satellite, and Christian/Children content filtering
> proxies who I recall can be the worst.
>
>
>
> You are correct that it is not the right way to do it in HTTP 1.1, however
> in HTTP 1.0 the behaviour was unspecified for Pragma: no-cache in the
> response header.
>
> Most caches ignore it but some will honour it and ignore the others.
>
>
>
> I don’t know that there is a completely correct answer for a messy
> internet.
>
>
>
> John B.
>
>
>
> On Feb 27, 2015, at 10:28 PM, Breno de Medeiros <breno at google.com> wrote:
>
>
>
>
>
> On Fri, Feb 27, 2015 at 1:15 PM, Brian Campbell <
> bcampbell at pingidentity.com> wrote:
>
> Thanks Breno,
>
> I see you've got "Pragma: no-cache" there, which according to both RFC
> 2616 <http://tools.ietf.org/html/rfc2616#section-14.32> and RFC 7234
> <https://tools.ietf.org/html/rfc7234#section-5.4> isn't defined for the
> response and isn't reliable for anti-caching. Having read that is what led
> me to bringing this thread up in the first place. But I generally assume
> that Google knows what they're doing so I have to ask - do you know why
> that particular one is being used?
>
>
>
> I am not an expert on caching, but my understanding is that nearly all
> clients compliant with HTTP 1.1 will process the 'modern' caching directive
> on the cache-control entry and ignore pragma that comes later. However,
> there are transparent caching proxies (or there used to be until
> uncomfortably recently, specially in some regions of the world) that are
> not actually HTTP 1.1 compliant (but allow the declaration from the
> downstream client to be asserted, which they need to in any case). These
> very old and bizarre proxies don't process correctly the cache-control
> directive, but obey the older (HTTP 1.0) pragma directive, which is better
> than nothing.
>
>
>
>
>
>
>
>
>
> On Thu, Feb 26, 2015 at 7:45 PM, Breno de Medeiros <breno at google.com
> > wrote:
>
> FWIW, the cache headers returned for some Google sensitive pages are:
>
>
>
> Cache-control: no-cache, no-store
>
> Pragma: no-cache
>
>
>
> The answer to the questions are yes and yes (where the first 'yes' should
> mean to say 'modify the headers to a commonly agreed value that has clearer
> no-caching semantics').
>
>
>
>
>
> On Thu, Feb 26, 2015 at 3:51 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> If you can change "sensitive" to something else, I would be fine.
> "Sensitive" has some connotation in the field of privacy and I do not want
> confusion there.
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2015-02-26 23:28 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>
> I'm fine with not wanting to use the word 'sensitive' but the text you
> proposed doesn't seem quite right.
>
> While the "no-store" definition does mention non-volatile storage, it also
> talks about volatile storage and, as I read it, pretty much says don't
> store any part of the response or associated request, ever. From the text,
> quoted again below, I don't see how "no-store" is possibly insufficient.
> 5.2.2.3 <https://tools.ietf.org/html/rfc7234#section-5.2.2.3>.  no-store
>
>
>
>    The "no-store" response directive indicates that a cache MUST NOT
>
>    store any part of either the immediate request or response.  This
>
>    directive applies to both private and shared caches.  "MUST NOT
>
>    store" in this context means that the cache MUST NOT intentionally
>
>    store the information in non-volatile storage, and MUST make a
>
>    best-effort attempt to remove the information from volatile storage
>
>    as promptly as possible after forwarding it.
>
>
>
> Based on the text in the spec, I'm having a hard time understanding the
> push back on using "no-store".
>
> From a practical perspective, however, I am not well versed in what
> browsers and intermediate caches actual do and don't honor well. Generally,
> when I want to prevent something from being cached, I throw a bunch of
> anti-caching directives at the response and it just works out. To your
> point earlier, that kind of thing isn't exactly appropriate for normative
> text. Note also that there's not a implementation considerations section in
> this doc and we're trying to make only very small changes at this point.
>
>
>
> As a compromise, of sorts, what about some text like this:
>
>
>
> "Because the Authorization Response is intended to be used only once, the
> Authorization Server MUST instruct the User Agent (and any intermediaries)
> not to store or reuse the content of the response."
>
>
>
> And then, in the non-normative example, just throw in the whole kitchen
> sink of cache prevention headers like:
>
>
>
> Cache-Control: no-cache, no-store, max-age=0, must-revalidate, private
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
>
> ?
>
>
>
>
>
> On Tue, Feb 24, 2015 at 5:41 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> Thanks Brian.
>
>
>
> A friendly amendment to your proposed change:
>
>
>
> Rationale
>
> -----------------
>
> 'sensitive' is either undefined or has other connotation especially in the
> privacy realm, thus it probably is better to avoid the word in this
> particular case.
>
>
>
> Also, "no-store" in our case is insufficient as cache control because it
> is just concerned with a non-volatile storage.
>
>
>
> Proposal
>
> --------------
>
> Change:
>
> Because the Authorization Response contains sensitive information, the
> Authorization Server MUST include the HTTP "Cache-Control" response header
> field [RFC2616] with a value of "no-store" in the response.
>
>
>
> To:
>
> Because the Authorization Response contains the information that cannot be
> re-used, the Authorization Server MUST include the HTTP "Cache-Control"
> response header field [RFC7234] with values "no-cache" in the response.
>
>
>
>
>
> I have a slight concern about "no-cache" implementation state as RFC7234
> says that it is not obeyed in some caches.
>
> "no-cache" is semantically equivalent to , "max-age=0, must-revalidate".
> Perhaps it may be better to add that in practice, but it seems it is
> inappropriate to have it in a normative text. Perhaps a note in an
> implementation consideration may be good.
>
>
>
> Nat
>
>
>
>
>
> 2015-02-25 0:15 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>
> And it just (re)occurred to me that RFC 2616 has been obsoleted. So the
> reference in the text that I proposed in the last message should probably
> be to RFC 7234 rather than RFC 2616.  Also the current reference in the
> Form Post Response Mode to RFC 2616 for the "User Agent" term should
> probably be updated to RFC 7230.
>
>
>
> On Tue, Feb 24, 2015 at 8:03 AM, Brian Campbell <
> bcampbell at pingidentity.com> wrote:
>
> I think it'd be okay to have the "no-cache" directive the example as well,
> if folks are keen on that. But it doesn't replace "no-store". The example
> could have both like, "Cache-Control: no-cache, no-store". I don't think
> it's necessary as "no-store" is the stricter but I think it's okay to have
> it there too.
>
> On the call yesterday
> <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150223/005280.html> I
> asked if folks thought there should also be normative text in the Form Post
> Response Mode doc about not caching the authorization response containing
> the auto-submitting HTML form. There's some text in §5.1 of RFC 6749 /
> OAuth 2.0  <http://tools.ietf.org/html/rfc6749#section-5.1>that could be
> interpreted as obviating the need for it, which says that the
> 'authorization server MUST include the HTTP "Cache-Control" response header
> field [RFC2616] with a value of "no-store" in any response containing
> tokens, credentials, or other sensitive information'.  However, that's in a
> section about the token endpoint and so could also be interpreted as not
> applying to the authorization response from the authorization endpoint at
> all. Thus, I'm (sorta) proposing to add the following sentence to the end
> of §2 of OAuth 2.0 Form Post Response Mode
> <http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html#FormPostResponseMode>,
> 'Because the Authorization Response contains sensitive information, the
> Authorization Server MUST include the HTTP "Cache-Control" response header
> field [RFC2616] with a value of "no-store" in the response.'
>
>
>
> On Mon, Feb 23, 2015 at 4:55 PM, Brian Campbell <
> bcampbell at pingidentity.com> wrote:
>
> But that text is about directives on the cache-control _request_ header.
>
> The directives in question here are on the _response_.
>
> https://tools.ietf.org/html/rfc7234#section-5.2.2 is about the response
> directives. With https://tools.ietf.org/html/rfc7234#section-5.2.2.3 saying
> this about "no-store",
>
>    The "no-store" response directive indicates that a cache MUST NOT
>
>    store any part of either the immediate request or response.  This
>
>    directive applies to both private and shared caches.  "MUST NOT
>
>    store" in this context means that the cache MUST NOT intentionally
>
>    store the information in non-volatile storage, and MUST make a
>
>    best-effort attempt to remove the information from volatile storage
>
>    as promptly as possible after forwarding it.
>
> While "no-cache" at https://tools.ietf.org/html/rfc7234#section-5.2.2.2 isn't
> as strong:
>
>    The "no-cache" response directive indicates that the response MUST
>
>    NOT be used to satisfy a subsequent request without successful
>
>    validation on the origin server.  This allows an origin server to
>
>    prevent a cache from using it to satisfy a request without contacting
>
>    it, even by caches that have been configured to send stale responses.
>
>
>
>
>
> On Mon, Feb 23, 2015 at 4:39 PM, Mike Jones <Michael.Jones at microsoft.com
> > wrote:
>
> Brian, “Cache-control: no-store” does not seem to imply “Cache-control:
> no-cache”.  I say that because of this sentence in 5.2.1.5 of
> https://tools.ietf.org/html/rfc7234#section-5.2.1:
>
>
>
>    Note that if a request containing this directive is satisfied from a
>
>    cache, the no-store request directive does not apply to the already
>
>    stored response.
>
>
>
> Therefore, to be safe, I believe that we have to replace the “Pragma:
> no-cache” in our example with “Cache-control: no-cache”.
>
>
>
> Do people agree with that conclusion?
>
>
>
>                                                             -- Mike
>
>
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
> *Sent:* Thursday, February 19, 2015 7:19 PM
> *To:* Mike Jones
> *Cc:* Brian Campbell; <openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example has
> 'Pragma: no-cache'
>
>
>
> Yes and yes.
>
>
>
> On Feb 19, 2015, at 5:08 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>
>
> First question to the working group:  Do we agree that "Pragma: no-cache" should
> be changed to "Cache-Control: no-cache" in the Form Post Response Mode
> spec before approval?
>
>
>
> Second question to the working group:  If we agree to make this change (to
> text that only occurs in a non-normative example), are people comfortable
> doing this without restarting the 60 day review period (but still notifying
> people of the change)?
>
>
>
> My personal answers would be “yes” and “yes” but we shouldn’t do this at
> this point unless there’s working group consensus to do so.
>
>
>
> Brian, could you also send a note to the OAuth working group pointing this
> problem with RFC 6749 and RFC 6750 and asking whether errata should be
> filed?  This would help get more expert eyes on the issue.
>
>
>
> Thanks for bringing this to our attention, Brian!
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net
> <openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of *Brian Campbell
> *Sent:* Thursday, February 19, 2015 2:17 PM
> *To:* <openid-specs-ab at lists.openid.net>
> *Subject:* [Openid-specs-ab] Form Post Response Mode example has 'Pragma:
> no-cache'
>
>
>
> The example response in
> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0-03.html#FormPostResponseExample has
> a "Pragma: no-cache" response header.
>
> However both RFC 2616 <http://tools.ietf.org/html/rfc2616#section-14.32> and
> the shiny new RFC 7234 <https://tools.ietf.org/html/rfc7234#section-5.4> make
> special note along the lines of the following to say that it doesn't work
> as response header:
>
>       'Note: Because the meaning of "Pragma: no-cache" in responses is
>
>       not specified, it does not provide a reliable replacement for
>
>       "Cache-Control: no-cache" in them.'
>
>
> It doesn't really hurt anything having it in the Form Post Response Mode
> document but I'm thinking it'd be better to not further perpetuate the
> "Pragma: no-cache" response header myth in this specification* and that
> that line should probably be removed from the example.
>
> Or am I wrong on this? And if so, what am I missing?
>
>
>
> * And, yeah, it's in Connect Core and OAuth 2.0 as well but I figured
> starting with a draft that wasn't yet final was good.
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
> --
>
> --Breno
>
>
>
>
>
>
>
> --
>
> --Breno
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>   _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150302/0bbfa93d/attachment-0001.html>


More information about the Openid-specs-ab mailing list