> seems to me, this confusion & potential issues are reasons to /not/ specify > the header name as "Frame-Options" (for now), given "X-FRAME-OPTIONS" > apparent wide use.
Sounds OK to me though I'd just want to be careful to do whatever the standards process dictates here. I have to imagine there's a precedent we'd want to follow. David Ross [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of =JeffH Sent: Friday, July 08, 2011 12:41 PM To: IETF WebSec WG Subject: Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01) > I agree it would be good to get the ALLOW-FROM in the draft consistent with > > [2]. super. > The major difference does seem to be the fact that the RFC supports a > > list of origins for ALLOW-FROM, whereas [2] does not. yep. >> Also, the header name is declared as "Frame-Options" rather than what's >> >> presently implemented and deployed: "X-FRAME-OPTIONS". > > Since the RFC will standardize it, I think it may be appropriate to drop the > > X- prefix. But then also we should probably have the RFC draft > explicitly > specify the behavior if there are multiple conflicting > X-FRAME-OPTIONS / > FRAME-OPTIONS headers present in a given HTTP response. > (Eg: What happens > if there is both an X-FRAME-OPTIONS and a > FRAME-OPTIONS header, each with > ALLOW-FROM directives pointing to > different sites?) seems to me, this confusion & potential issues are reasons to /not/ specify the header name as "Frame-Options" (for now), given "X-FRAME-OPTIONS" apparent wide use. FWIW, we can make this "X-FRAME-OPTIONS" spec be on the Informational or Experimental track. Microsoft already has a modest passel of specs in the former group. thanks, =JeffH _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
