HTML5 and cache-control
Will Roberts
<meta http-equiv="Cache-Control" content="no-cache">
is in interpreted. Is there a new way of doing that?
Also, what determines when a file should expire if none of the cache
management/expiration headers are set? While playing with variations of
the meta tag above and looking at about:cache I saw times that varied
from the current time, to a few seconds in the future, to as much as 50
minutes in the future!
Thanks,
--Will
Benjamin Hawkes-Lewis
> When using the html5 parser, it doesn't seem like
>
> <meta http-equiv="Cache-Control" content="no-cache">
>
> is in interpreted. Is there a new way of doing that?
"http-equiv='Cache-Control'" is not conforming in the current HTML5 draft:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-pragma-directives
I don't see any text requiring user agents
to ignore it, but the "new way" would be the old way: real HTTP headers.
--
Benjamin Hawkes-Lewis
Boris Zbarsky
> Also, what determines when a file should expire if none of the cache
> management/expiration headers are set?
RFC 2616 section 13.2.2:
13.2.2 Heuristic Expiration
Since origin servers do not always provide explicit expiration
times, HTTP caches typically assign heuristic expiration times,
employing algorithms that use other header values (such as the
Last-Modified time) to estimate a plausible expiration time. The
HTTP/1.1 specification does not provide specific algorithms, but
does impose worst-case constraints on their results. Since
heuristic expiration times might compromise semantic transparency,
they ought to used cautiously, and we encourage origin servers to
provide explicit expiration times as much as possible.
In the case of necko, the heuristic for cases when neither Max-Age nor
Expires is set is that the expiration time is:
now + 1/10 * (date - last-modified)
where "now" is the current time (more or less; there's some adjustment
that might make it "the time when the request was sent to the server"),
"date" is the value in the Date header or the current time if there is
no Date header, and "last-modified" is the value of the Last-Modified
header. This heuristic is only used if the Last-Modified header is set,
and if the time given in it is >= "date". Otherwise, the expiration
time is set to "now".
See also nsHttpResponseHead::ComputeFreshnessLifetime.
> While playing with variations of
> the meta tag above and looking at about:cache I saw times that varied
> from the current time, to a few seconds in the future, to as much as 50
> minutes in the future!
Right. It could also be hours, days, months, etc, for resources which
haven't changed in a long time (so that |date - last-modified| is large.
-Boris
Will Roberts
<bhawkesle...@googlemail.com> wrote:
> "http-equiv='Cache-Control'" is not conforming in the current HTML5 draft:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics...
>
> I don't see any text requiring user agents
> to ignore it, but the "new way" would be the old way: real HTTP headers.
>
> --
> Benjamin Hawkes-Lewis
So even if the page is HTML4 compliant, and specifies the HTML4
doctype, the parser still ignores those tags? Isn't that going to
break pages that rely on that behavior? It isn't always possible to
set HTTP headers, I figured that was why the http-equiv meta tags were
introduced. Should I file this as a regression against the html5
parser?
--Will
Boris Zbarsky
> So even if the page is HTML4 compliant, and specifies the HTML4
> doctype, the parser still ignores those tags?
The parser ignores the doctype, except for deciding whether we should be
in quirks mode. But see below.
> Isn't that going to break pages that rely on that behavior?
If it is, then the spec presumably needs changing.
> I figured that was why the http-equiv meta tags were introduced.
They were _originally_ introduced so that you could specify in your HTML
what headers the server should send with it. Technically, per the
letter of HTML4, client software doing anything at all with http-equiv
is a spec violation.
> Should I file this as a regression against the html5 parser?
It's worth filing it in the W3C bugzilla as a bug against the html5
spec, perhaps.
-Boris
Arivald
So, how to specify character encoding for HTML5 document on disk?
Currently I use
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
But if HTML5 parser may ignore it...
<some time....>
Ok, i checked in spec, there is new META,
<meta charset="UTF-8">
--
Arivald
Henri Sivonen
>
> Currently I use
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>
> But if HTML5 parser may ignore it...
It is not ignored, and the spec requires doing stuff with it. (The processing of the charset stuff is *very* different from anything else that lives in meta tags.)
Back to cache-control: Does anyone happen to have a test case demonstrating whether cache-control in a meta is being honored?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Boris Zbarsky
> Back to cache-control: Does anyone happen to have a test case demonstrating whether cache-control in a meta is being honored?
http://landfill.mozilla.org/ryl/meta-cache-control.cgi
-Boris
Boris Zbarsky
And if you want, I can create a control that is identical except for the
<meta> tag.
-Boris
Arivald
>> So, how to specify character encoding for HTML5 document on disk?
>>
>> Currently I use
>> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>>
>> But if HTML5 parser may ignore it...
>
> It is not ignored, and the spec requires doing stuff with it.
http://www.w3.org/TR/html5-diff/#character-encoding
--
Arivald
Boris Zbarsky
Right. That says pretty much what Henri said, no?
-Boris