Walter,
On May 7, 2005, at 8:19 PM, Walter Underwood wrote:
Architecturally, this is exactly the same as HTTP-EQUIV meta tags for HTTP headers, and very similar to the ROBOTS meta tag for /robots.txt. In both cases, they provide a way for the document author to specify something without having permissions on the server software config.
Further, these should be implemented exactly like HTTP-EQUIV, where the server software reads them and sets the header.
Servers don't do this with HTTP-EQUIV because it's too much of a performance hit; HTTP-EQUIV was a nice idea that never took off.
The HTTP-EQUIV meta tag is proof "put it in the header" is not good
enough for everything else. If that wasn't needed, it would be deprecated
by now.
I'm sympathetic to this problem, but I think the right answer is to fix the server configuration mechanisms, not to mix transport issues into formats.
There is a problem here, though. We need to specify the priority of the
in-document specs vs. the HTTP header specs. I propose following the HTTP
standard, in saying that the HTTP headers trump anything in the body.
I'll even assume that following the HTTP spec is non-controversial, and
go update the PACE
This was the approach taken in determining the character encoding for XML, and it cause a lot of confusion and problems.
Also, realise that HTTP's caching mechanism is very much reliant on the constraints of HTTP; Expires brings clock sync issues, and max-age places requirements on the behaviour of intermediaries. It's not very easy to abstract these away into a generic mechanism.
So, I'm -1 to PaceCaching.
Cheers,
-- Mark Nottingham http://www.mnot.net/
