caches and negotiated content, was Re: Layout is breaking in NN7using CSS Style

On Mon, 17 May 2004, Brian wrote:

Mark Tranchant wrote:

Maybe in theory, but I could not persuade my work proxy to cache both
types, leading to IE asking me if I wanted to download my pages...!

That's a fault in IE, but surely unrelated to caching. (No?)

What Mark is saying, I think, is that the proxy had cached the
real-XHTML(tm) variant (when it had been requested by some
XHTML-capable browser), and then along came IE, asking for negotiated
content, and the cache handed -it- a copy of the previously-cached
XHTML, instead of finding out from the origin server that this client
would need the text/html variant instead.

I had a terrible time with IE 5.x and content negotiation. I wrote
up a pretty full account, along with a test case, in
ciwa.site-design some time ago.

I vaguely remember that, but google shows threads in *.stylesheets
in late Feb and also in mid April. Could you help us out with a
specific reference, please?

Unfortunately, even without the extra complications resulting from
IE's misbehaviour, it's hard to debug this kind of stuff by remote
control. It really needs someone who can actually view the headers
coming from the origin server, and if those turn out to be "to
specification", then ideally one also wants some insight into what the
proxy is doing. And then with IE you have to work out (or at least
guess) which of its various dirty tricks is leading to its
misbehaviour.

I think I would want to first try some browser whose HTTP behaviour is
expected to be to-spec, and ideally whose Accept header can be
configured. Me, I'd probably choose Lynx for that. IE can be brought
into the picture later, after any other misleading factors have been
eliminated.

But I'm afraid I'm tied up with other work at the moment and so I'm
not volunteering to take this investigation forward in detail, even if
I'd be interested to hear the results.

Btw, I saw yet again today someone asserting that IE *always* goes by
filename extension. That simply isn't true, no matter how often it
gets repeated. As the notorious MS "moniker" page documents: for the
MIME content-types which are on its hit-list, IE deliberately
disregards the only piece of information which RFC2616 permits it to
use, and instead uses several different factors - of which the
filename extension is only a last resort. Sigh.

Brian wrote:

Alan J. Flavell wrote:
What Mark is saying, I think, is that the proxy had cached the
real-XHTML(tm) variant (when it had been requested by some
XHTML-capable browser), and then along came IE, asking for negotiated
content, and the cache handed -it- a copy of the previously-cached XHTML

Arrgggghhh!

Funny - that's exactly what I said, too.

--
Mark.

Brian wrote:

Have you looked at your vary headers? I'm afraid I'm only barely
treading water on such matters, but from reading about headers at the w3c

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44

it seems that cacheability is affected by vary headers. In principle, at
least, a proxy should only deliver a cached document that was retrieved
using the same request, right? Is your server is sending out a vary
header for content-type?

Using Rex Swain's excellent tool:

Vary: negotiate,accept,Accept-Encoding,User-Agent

--
Mark.

On Tue, 18 May 2004, Mark Tranchant wrote:

Brian wrote:

it seems that cacheability is affected by vary headers.

that's the way it's meant to be, indeed...

In principle, at least, a proxy should only deliver a cached
document that was retrieved using the same request, right?

Depends. If it's got the capability, the cache can send the origin
server an "if-none-match" request, listing the ETags of the ones which
it has; the server can return a 304 response showing the ETag of the
appropriate resource, then the cache can hand out the
previously-cached resource without retrieving a duplicate copy.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26

Or sometimes the origin server will respond by sending a Location:
redirection to a static resource, and maybe the cache already has that
resource on hand. It just depends how the server is implemented.
But for sure if the cache hasn't got a match for the precise
constellation of the vary headers, then it *should* ask. (And since
the likelihood of the user agent string matching precisely is rather
low, then by including user-agent in the negotiation it's almost as
bad as sending "cache-control: private", in its effect on
cacheability. It's best avoided except as a last resort. That's the
theory, anyway.

I won't deny that sometimes things don't seem to work in the real
world in quite the way that the theory implies. But I'm afraid that
in the past I've seen information providers shovelling-in every
possible anti-cacheing weapon (Pragma: no-cache, Expires dates in the
past, unsolicited query strings appended to static URLs, etc. etc.
etc.) in the hope of bludgeoning their way out of a problem: well, it
doesn't always solve the original problem, but it sure can cause
readers some new ones, especially if they're on low b/width or flakey
networks. And sometimes also when they aren't.

Using Rex Swain's excellent tool:

Vary: negotiate,accept,Accept-Encoding,User-Agent

I can't see anything technically faulty with that, aside from the
points that I've already made.

best I can offer at the moment, sorry.