This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28563 - As in most cases the http-equiv meta tags are equivalent to their corresponding HTTP header, would i [...]
Summary: As in most cases the http-equiv meta tags are equivalent to their correspondi...
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other All
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: https://html.spec.whatwg.org/#attr-me...
Whiteboard:
Keywords:
Depends on: 28339
Blocks:
  Show dependency tree / graph
 
Reported: 2015-04-27 07:40 UTC by contributor
Modified: 2017-08-09 09:49 UTC (History)
6 users (show)

See Also:

Attachments

Description contributor 2015-04-27 07:40:12 UTC 
Specification: https://html.spec.whatwg.org/
Multipage: https://html.spec.whatwg.org/multipage/#attr-meta-http-equiv-refresh
Complete: https://html.spec.whatwg.org/#attr-meta-http-equiv-refresh
Referrer: 

Comment:
As in most cases the http-equiv meta tags are equivalent to their
corresponding HTTP header, would it be worth mentioning in step 24 that the
automatic features sandbox should not affect the corresponding Refresh HTTP
header.

I'm assuming that is what is intended and certainly blink allows the header
when sandboxed.
Either way it would be useful to make it clear.

I am currently implementing the same behaviour as blink for gecko.

Thanks,
Bob Owen

Posted from: 80.189.213.41
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Comment 1 Ian 'Hixie' Hickson 2015-05-05 21:35:42 UTC 
I presume whether it affects the header or not should be up to whatever spec defines the header. Which spec defines the header?

Why would we not want the header to work the same way? Presumably any reason that applies to the <meta> element applies to the header too, no?
Comment 2 Bob Owen 2015-05-06 09:05:00 UTC 
Copying in Boris, as he was involved in a brief discussion that we had about this.
Comment 3 Boris Zbarsky 2015-05-06 15:33:14 UTC 
> Which spec defines the header?

There is no spec defining the refresh header that I know of.  Netscape made it up and no one ever standardized it.

> Why would we not want the header to work the same way?

That depends on what our goals are, I guess.  If we're sandboxing source we don't fully trust that we put on our server, then there is a fundamental difference between <meta http-equiv="refresh"> and the refresh HTTP header: the former is under the control of the untrusted source, while the latter is under our control.

If, on the other hand, we're sandboxing some URI loaded from some other server, then it makes sense to me to disallow the HTTP header too...
Comment 4 Ian 'Hixie' Hickson 2015-05-06 16:02:20 UTC 
Makes sense. In any case, the answer is someone should write a spec for it.

I'm happy to add a note to the HTML spec saying that there's no HTTP header of this name defined, but that if there was, one should not assume it acts like the pragma.
Comment 5 Anne 2017-08-09 09:49:46 UTC 
Per the current PR for this the Refresh works in combination with sandboxing since that's what Chrome already did:

  https://github.com/whatwg/html/pull/2892