views:

218

answers:

1

Hi,

I have a server/client architecture where the client hits the ASP.NET server's service at a certain host name, IP address, and port. Without thinking, I logged on to the server and set up permanent HTTP301 redirection through IIS from that service to another URL that the machine handles via IIS (same IP and port), mistakenly thinking it was another site that is hosted there. When the client hit the server at the old host name, it cached the permanent redirect. Now, even though I have removed the redirection, the client no longer uses the old address. How can I clear the client's cache so that it no longer stores the redirect?

I have read about how permanent HTTP301 can be, but in this case, it should be possible to reset a single client's knowledge of the incorrectly-learned host name. Any ideas?

A: 

The HTTP status code 301 is unambiguously defined in RFC 2616 as

any future references to this resource SHOULD use one of the returned URIs

which means you have to go ask all your clients to revalidate the resource. If you have a system where you can push updates to your clients, perhaps you can push an update to use the same URI again, but force a revalidation.

Nothing you do on the server side will help - in fact, by removing the permanent redirect in IIS you have already taken all measures you should.

bzlm
I have only one client, and have direct access to it. I'm talking about a potential client-side modification here.
ChessWhiz
If you modify your client to not obey RFC 2616, then you may run into problems later. Why not just use *moved temporarily* instead of *moved permanently* in the future?
bzlm
I will, after this mess. The client must be storing the redirection information somewhere, though, and I have removed the HTTP301 response from the server, so that's why it should be able to be cleared without violating RFC 2616 for that client. (I don't mind if the client stores future HTTP301's, because the server no longer serves them.)
ChessWhiz
"I have removed the HTTP301 response from the server, so that's why it should be able to be cleared without violating RFC 2616 for that client" - it won't, since the client must remember that "any future references to this resource SHOULD use one of the returned URIs". If you encounter a permanent redirect with your own end-user browser, it will be stored in your private data cache. Who is this mysterious client, anyway?
bzlm
Glad it worked out. :)
bzlm