RE: IE vs vary header

Again,

thanks for the feedback...

> ...
> > Of course you are right -- if and only if "user-agent" is added to
> > the Vary header. I'd like to avoid that, because that adds yet
> > another dimension.
>
> Oh, I see. In this context, you cannot negotiate depending on user
> agent without adding User-Agent to the Vary header and you have to
> negotiate based on user agent if you want to work around user agent
> bugs.

Great :-)

> > And even if I do that, the second scenario still can happen,
> > right?
>
> The second scenario should not happen if you mark Vary-less responses
> as uncachable. You have to mark them as uncachable for the
> Apache-suggested work-around to make sense in your case (IMO).

I think if I mark them as un-cacheable, the *same* problem in IE will
occur -- it fails to pass content to external applications if it decides
that the content is not cacheable (their logic is: we pass data to external
programs by caching it, but the response headers indicate that the result
isn't cacheable, thus we can't pass it on -- funny, isn't it?).

> > What are these other, more robust mechanisms?
>
> There are probably several such mechanisms. The simplest is to mark
> all negotiated content as uncachable and return no Vary headers, but
> there may be more elegant solutions. For example, would it be possible
> to change the URL (using an HTTP redirect response) based on the
> request headers or based on whatever you are using to negotiate? You
> could redirect all IE clients to their own URL "space" that does not
> use Vary while using default URLs for other clients.  Changing URLs
> solves all solvable problems caused by broken caches. The redirection
> and its side-effects must be handled transparently to the user and
> content author, of course.

That's very good input -- I'll try that.

Received on Wednesday, 19 June 2002 12:13:46 UTC