Richard: 1. I disagree with you, but more to the point...
2. ...do you really think this meets the DISCUSS criteria? Barry On Mon, Aug 19, 2013 at 11:42 AM, Richard Barnes <[email protected]> wrote: > > > > On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom > <[email protected]> wrote: >> >> On 19/08/13 15:48, Richard Barnes wrote: >> >> >> >> >> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <[email protected]> >> wrote: >>>> >>>> > (D2) It seems like this is a value that browsers might cache, to avoid >>>> > unnecessary requests if the same page is framed in the future. If >>>> > this >>>> > is something browsers do today, please say so. >>>> >>>> Actually I like to push back in this case, as I don't think we should go >>>> into implementation specific details that have no effect on the bits on >>>> the wire nor on the effective behavior of the browser. >>>> The X-Frame-Options header determines the behaviour for every individual >>>> requested page regarding framing in another web page in the browser. >>>> Whether the browser caches this information and compares the request >>>> with an existing cache from a request from before AND if the value is >>>> identical proceeds as before or whether the browser evaluates the >>>> X-Frame-Options header on each request should not be specified in this >>>> draft. >>> >>> >>> I'll note also that this is particularly the case because this is >>> documenting something that exists, but that isn't recommended for >>> implementation. If this were a PS that we were recommending for new >>> implementations, it might make more sense to talk about how to do caching >>> for better implementations. >>> >>> Barry >> >> >> I understand. Caching is just another aspect of existing implementation >> behavior that I think should be documented. >> >> Of course, I may be off base here. If nobody does it, and people think >> it's patently obvious that you never would, then I could clear. >> >> --Richard >> >> >> Richard, >> >> in short: I think, we really don't need and in fact should not discuss >> caching of the existing implementations in this draft. >> >> Some info fyi: >> caching has only very limited (or no) benefit here. Because the browser >> has to check for every http-request of the resource whether the >> X-Frame-Options header has been set and then act accordingly. It is also a >> very simple check. >> >> And consider as a page itself might be dynamic, the header can change with >> it, too. >> >> As mentioned in my answer before the only mini advantage of caching might >> be that the browser sees the header is still the same as before (with a >> simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again >> e.g. if ALLOW-FROM is set if you already did so in your previous call. >> But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in >> which case the comparison of the header with the previous one would not be >> much cheaper than to just run the regex rule for the header itself. >> >> And also, as outlined in section 2.3.2.3., servers may generate >> X-Frame-Options header responses depending on the request. >> Example case: Consider that we have only one serialized-origin in the >> ALLOW-FROM directive. Now imagine a user has multiple pages open in his >> browser tabs with one of web page 1 from domain A and the second of web page >> 2 from domain B both frame the same page from domain C with the ALLOW-FROM >> directive. In that case the page needs to reply to both requests with >> different X-Frame-Options headers, the first pointing to origin A, the >> second to origin B. >> But then many implementations don't support the ALLOW-FROM directive.... >> >> So to summarize my answer: we really don't need and in fact should not >> discuss caching of the existing implementations. >> >> All the best, Tobias > > > Again, I'm not looking for an analysis of the merits here, just what current > browsers do. It looks like Firefox doesn't cache anything [1], but I don't > know about other browsers. If anyone does, then this document should warn > people. If there are no known instances of caching, I'll just clear. > > In a related vein, the code below demonstrates that at least Firefox *will* > accept a URI with ALLOW-FROM, and (correctly) do the comparison based on the > origin of that URI. If other browsers do this, then with regard to (D3), it > seems this document should probably say that the header *syntax* allows a > URI, but the *comparison* is done based on the origin of the URI (Section 4 > of RFC 6454). > > Thanks, > --Richard > > [1] > <http://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361> > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
