This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/semantics.html Multipage: https://html.spec.whatwg.org/multipage/#attr-meta-http-equiv-refresh Complete: https://html.spec.whatwg.org/#attr-meta-http-equiv-refresh Referrer: https://html.spec.whatwg.org/multipage/ Comment: <meta refresh> Specify Refresh HTTP header Browsers support it, some Web content uses it. (36 pages in webdevdata have Refresh header but no <meta refresh>) Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.50 Safari/537.36 OPR/29.0.1795.26 (Edition beta)
What's this got to do with HTML? Isn't this an HTTP bug?
I don't know, it seems to me that navigating browsing contexts is HTML material.
Yeah, we can add this to HTML. I'll add it to my list.
See Also https://github.com/httpwg/http-extensions/issues/138 with some data for the patterns found on the Web and a couple of tests. http://www.otsukare.info/2015/03/26/refresh-http-header
This is what I have thus far: * Most of the algorithm at https://html.spec.whatwg.org/#attr-meta-http-equiv-refresh can be abstracted into a standalone algorithm (step 5 and onward looks like). * That new algorithm basically takes a string and a document. Though we'll also need to account somehow for the meta element insertion time if that's later than the document is created. Easiest would be to just pass in the meta element and null if it's from a header. And if it's null we don't apply the sandboxing as per bug 28563. * When navigation has created a document, we check if there's a Refresh header and then if there is decode the value of that header with "original ISO-8859-1" (map each byte to a code point that has the same value). Then pass that code point sequence and the created document to the new standalone algorithm. * Basic tests: https://github.com/w3c/web-platform-tests/pull/6606 The algorithm should probably also queue a task and navigate from that task. You can't really navigate out of thin air as it tries to do now.
Other things to take into account: * Multiple Refresh headers * Conflicts between headers and elements (probably a single flag on Document objects would do, need to test) * https://github.com/whatwg/html/pull/2865
It seems the processing model for multiple Refresh headers is that the values get combined (comma-separated, etc.). It's not clear to me this is good (Firefox doesn't do it for Location): https://bugzilla.mozilla.org/show_bug.cgi?id=1387032.
+tyoshino to see if we can get any Chrome network team thoughts on comment #7.
Defining Refresh in general: https://github.com/whatwg/html/pull/2892 Multiple headers: https://github.com/whatwg/html/issues/2900