- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 Jun 2002 18:13:05 +0200
- To: "Alex Rousskov" <rousskov@measurement-factory.com>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: <ietf-http-wg@w3.org>
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