IIS 7 and Above
how to change domain name used for Application Initialiation's initia...
Last post May 09, 2013 02:50 AM by carehart
May 06, 2013 09:20 AM|carehart|LINK
To anyone who has used the new Application Initialization with IIS 7.5, have you ever found it to call a domain name other than localhost, when it calls the page listed in the initializationPage value? Even when it's configured for a site other than the
"default web site"?
For instance, I have a site named xyz, and its initializationPage value is "startup.abc" (not the real extension, but it's not relevant and could lead readers to misapprehend an explanation).
Yet, when I watch a monitor for the web application handling those .abc requests, I can see that when the initpage is executed, the URL generated by IIS is not
http://xyz/startup.abc but rather http://localhost/startup.abc (and indeed, the monitor also confirms that the user-agent of the request is "IIS Application Initialization Warmup".
So what does it take to get things to work correctly? I have not found anyone else reporting it, but I almost wonder if most people who report that "it's not working" are suffering the same problem--but they are confused into thinking it's not calling their
intended page because perhaps they have no monitor that can confirm the actual page executed.
And for what it's worth, the requests are NOT logged in the IIS logs. That doesn't surprise me as much, since resources on the feature do say that IIS throws away the page output (of the page called as the initializationPage).
But if anyone has any thoughts on what could help me solve this (or can confirm if they see other than localhost called for their background init page) I'd appreciate hearing from you.
May 07, 2013 07:36 AM|Pengzhen Song - MSFT|LINK
Implementing Application Initialization on IIS 7.5
And refer the similar thread
Hope it can help you
May 07, 2013 10:15 PM|carehart|LINK
@Pengzhen Song, thanks but no, none of those answer my question. I appreciate that perhaps many ask questions that seem fundamental, and therefore a little google/bing-fu can help get them going. In this case, I had read those and many more resources on
the feature long ago, and had read them again recently in trying to solve this specific problem, to no avail.
Let me repeat: I *AM* getting the initializationPage to execute. The feature is configured as shown in all such resources. What is NOT working is that the URL generated by IIS is always a call to localhost as the domain for that initializationPage, regardless
of whether the site does not respond to localhost. That just does NOT work if you need to configure this in a site that responds on another domain/IP address/host header.
It just does not seem that the feature is using the binding of the web site where it's located, in generating the URL used for the initializationPage, which is just wrong. (And given that we can browse a file from within IIS and it WILL generate the right
URL using the site's binding, it's not that IIS can't do this. It's just that curiously, it does not, with this feature.)
As for why no one else has addressed this, I suspect it's that most users who have blogged/documented the feature have just not needed to use other than localhost for their testing/demonstration. That's great for such purposes, but not for production deployment.
But I can't believe that it CAN'T be made to work. Surely MS would not make that grievous a mistake, would they?
May 08, 2013 12:26 PM|Perkinsville|LINK
You might consider creating a URL Rewrtie rule where the HTTP_HOST matches LOCALHOST and then redirect the request to the location your application requires.
May 09, 2013 02:50 AM|carehart|LINK
Thanks for that, Benjamin.
First, are you perhaps confirming that you also find that initpages configured in a site with a binding other than localhost still causes IIS to create a URL using localhost? That just seems wrong, doesn’t it? :-)
As for the proposed solution, that sure seems awkward, too. :-) We’d have to think to create such a rule for any initpage we had (and of course then we’d have to hope that there’s never a reason that a request on localhost for that path/file was not REALLY
meant to run on localhost, as the rule would preclude that.)
I do appreciate that it’s an out-of-the-box alternative, and I will give it a try. I just am dismayed that in trying to promote this seeming fundamental solution to others (now built into IIS 8) that I would have to mention this issue as well.
FWIW, I will note that I am doing this on 7.5, with the downloaded version, not the built-in one in IIS 8. Thanks for any additional thoughts you may have.