2

I have my production site's app pool to recycle every 2 hours or so. I noticed that when the first call to the site is made, the App Pool caches the base url (e.g. www.mysite.com). This makes sense as this is used to resolve relative paths in ASP.NET e.g. ~/MyFolder/MyPage.aspx, which is resolved to:

http://www.mysite.com/MyFolder/MyPage.aspx

However since the site can be reached via our host name e.g. 

http://masdfg.my.provider.net

IIS thinks the url is 

http://masdfg.my.provider.net/MyFolder/MyPage.aspx

As you can image, this causing an issue with SSL as well as others. How can I prevent this from happening?

UPDATE: The work around was to create a url redirect. If anyone knows how to prevent this let me know.

PhillyNJ
  • 3,859
  • 4
  • 38
  • 64
  • The app pool is recycled to clear un-used memory. We are also using a 3rd API which sometimes needs to be flushed. – PhillyNJ Dec 28 '12 at 21:38
  • 1
    Hi - The APP pool "caches" NOT crashes – PhillyNJ Dec 28 '12 at 22:02
  • In what way does ASP.NET cache it? Can you include some code where you see this cached value being returned? – Ashley Ross Jan 02 '13 at 21:36
  • Hi Ashley - in my code, I use "HttpContext.Current.Request.Url" to get the base url. This sometimes returns the incorrect url (see my question above) - In addition if I generate my asp.net links with "~/mypage.aspx", the ~ can be resolved to the wrong URL. – PhillyNJ Jan 02 '13 at 21:42
  • Are you sure that your site bindings in IIS are correct? IIS Root > Your Site > Right Click > Edit Bindings. Is there anything strange? – erichste Jan 03 '13 at 21:54

3 Answers3

1

I hope I've understood your question correctly, but please do let me know if I haven't.

It sounds like the sole issue you have is that when you write the links to the response they sometimes reference the wrong root URL.

I notice that you use ~/ . This would resolve and write the entire URL to the response I think. It is better to use only / when writing links to the response.

So in your example you would write /myfolder/mypage.aspx. The browser would then resolve the / to mean that it's from the root address of the site, whichever that may be.

Like I said, I hope I've understood your question correctly and apologies if I haven't.

The Bearded Llama
  • 3,036
  • 4
  • 20
  • 31
  • Thanks for commenting "The Bearded Llama" :) - Your suggestion is only a work-around. I am able to resolve my links in a similar way, but I am more interested on figuring out why IIS is doing this and how to prevent it, rather then working around it. I've add URL rewrites to help with the issue, but I sure wish I knew how to prevent it. – PhillyNJ Jan 03 '13 at 19:23
  • Well, it's not really a workaround, it's more keeping with DRY as well as not hardcoding things. Although, now I understand what your question was about. It sounds like it's an IIS setup issue. If you post your IIS setup, I'll be more than happy to have a look and try to help. – The Bearded Llama Jan 03 '13 at 21:54
1

I know it's a long shot, but I've had a similar problem with my IIS setup. I solved it by going to the already mentioned "bindings" window through "Edit Bindings".

Then I removed all the not wanted bindings, then adding the hostname www.mydomain.com the server should answer to.

Finally I edited the windows hosts file at 

%windir%\System32\drivers\etc\hosts

Adding the line

127.0.0.1 www.mydomain.com

This ensures that www.mydomain.com always resolves to the local computer.

After executing iisreset.exe as administrator my problem was over.

Erwin
  • 1,484
  • 1
  • 18
  • 32
1

HttpContext.Current.Request.Url is not a cacheable item. That value comes from the HOST value of the HTTP headers. Which means it is passed in to the application from the request.

The only time it should take that second URL is if the requests HOST value was masdfg.my.provider.net

There are three possible fixes here. The first is to set your bindings and have any requests to masdfg.my.provider.net be forwarded over to www.mysite.com

The second, because your primary issue appears to be about SSL is to get a unified communications (UC) SSL certificate and install that on your server. This would be to cover the mysite.com and masdfg.my.provider.net domain names.

The third is to simply create a separate IIS site which points to the exact same production directory as the first one. Each site would have only 1 domain name it's responsible for.

NotMe
  • 87,343
  • 27
  • 171
  • 245