This project is read-only.

Machine name in URLs

Sep 28, 2010 at 5:45 PM

I've got an interesting problem that I haven't seen (or, at least, haven't successfully searched for) in the discussions. Hopefully someone will have some ideas.

I'm trying to migrate a BE (1.6) set up from my company's Test machine to our QA machine.  When I set things up on Test, everything was just fine -- a couple tweaks here and there, and everything was working as it should.  (I've even got it set up as a multi-blog system, with 3 blog instances sharing the same codebase directory; I cheated by using directory junctions.)  Things appeared to go smoothly with the move to QA -- again, a couple tweaks and the pages were appearing.  However, anytime I click a link with a redirect (such as login) or a postback (such as saving settings), the URL is created with the machine name instead of the site.  For instance, if the URL should be "," it will be rendered as "" (where machineid.yyy.zzz if the FQDN of the box).

The QA machine is 2003 SP2 running II6.  It hosts several of our QA site versions, so the different sites answer to different host header values, but there are no IIS references in the site definition to the machine name.  The set up between Test and QA is, so far as I can tell, virtually the same.  (I know, a lot can be hiding in "virtually.")

The only clue I've had so far is with a couple images.  On Test, the image paths used Utils.AbsoluteWebRoot, but this broke on QA because it was creating a machine name URL.  Once I changed the paths to use Utils.RelativeWebRoot, things appeared as they should.  This would suggest that all the redirects and postbacks use AbsoluteWebRoot in their URL construction, but I'm hesitant to just restructure and recompile the BE base to, essentially, remove the use of AbsoluteWebRoot.  And it remains incredibly confusing that it would work so well in Test, but the same config would have this problem in QA.

Has anyone else encountered this sort of issue, and if so, how did you resolve it?  Are there any thoughts or suggestions on how I might remedy this problem?  Any assistance would be appreciated.


Sep 29, 2010 at 12:48 PM

If you have URL rewriting setup, this seems like one possible reason this could be happening.  Or if there is a firewall setup with NAT, that's the other possible explanation for this -- that comes to mind.

I think a simple solution would be to not remove AbsoluteWebRoot, but modify it so it is basically hard-coded.  But you can set it up to retrieve the value (the path) from the web.config file (as an app setting).  At least if you do this, you can easily change the path for when you are deploying this to different machines (test, QA, production), without having to recompile each time to put a different path in there.

AbsoluteWebRoot usually works and is convenient since it dynamically determines the host name.  The good thing is that because all the code (I think all) relies on this single property, it makes it easy to make an application wide fix.

Sep 29, 2010 at 6:43 PM

Thanks for the suggestions, Ben.  I've been looking into the issue some more and pretty much concluded that it's a configuration issue with the QA server.  The firewall is a good suggestion; the server is in our DMZ, so there definitely could be something there.

I was checking on the errors showing up in the event application log, and there's a wildly mangled message that appears to suggest the problem actually stems from a failure to server up something through js.axd or WebResource.axd.  Once that fails, the error bubbles through with the machine name in the URL, which hits our ISA server coming in through the firewall... and things just go downhill from there.  The end result is me seeing a URL with the machine name, which can't be resolved.

I surreptiously moved the blog set up onto the production box, and everything worked perfectly there:  no changes or tweaks at all from the content on test.  Clearly something's up with QA, so I'll have to get our network and/or tech services people on it.

I was being a little glib in saying I was thinking of removing the use of AbsoluteWebRoot.  More than likely I would have done something quite similar to what you had suggested, creating an app setting value and pulling that in during the AbsoluteWebRoot assignment.

Thanks again for the thoughts and suggestions; they definitely helped.