UPDATED 03/04/09
In response to some comments, a sample from the master page looks like this. This is not an asp.net control, this is hard coded html
<span class="topleft"><span class="bottomleft">About us</span></span>
This renders on the production server as
<span class="topleft"><span class="bottomleft">About us</span></span>
MYDOMAIN is the true domain name of our main site, NEWDOMAIN is a perfectly valid DNS entry which points to the same site.
UPDATED 02/04/09
All the URLS are absolute in the sense that they begin http://
I don't think this can be a browser issue as the actual rendered source code (viewed via view source) has been changed. Checked in both IE7/8 and Firefox 3 and witnessed same behaviour.
Original Question
I have an ASP.Net 2.0 application which has several master pages. This is essentially mocked up to look exactly like our main website, but because it runs on a different server all of the URLs for menu items etc are given absolute URLs to our main site.
This works fine on my development machine, but on the production server all of the URLs which are absolute are changing at runtime, but they still end up at the same pages when clicked.
Is this a DNS issue? Does ASP.Net do some DNS resoltion of URL's when the master page and content are merged? If so then why does it not have the same effect on my local machine, they are on the same domain.
No, it's not a DNS issue, and ASP.net doesn't do any DNS resolution. That's all the responsibility of the browser you're viewing the page in.
However, there are several circumstances that can lead to inconsistent URLs being served in the page's mark-up, which may be interpreted differently by the client's browser.
Browser's will always interpret a URL beginning "http://" the same way - it's an absolute URL, so the destination will always resolve to the same thing. Make sure all your URLs to your main site begin "http://".
URLs beginning "www." (no http://) will be treated as relative URLs - i.e. if the page containing the URL is at http://www.google.com, you're essentially asking for http://www.google.com/YourUrl. You'll find this almost certainly isn't the behaviour you're looking for.
URLs beginning with a leading slash (/) will be treated as absolute on the current domain. For example "/Tools", within Google will result in a request to "http://www.google.com/Tools". If there's no leading slash, the browser will treated the URL as being relative to the page currently being viewed (i.e. a URL of "Tools" when you're viewing a page in the "en" folder would result in a request to "en/Tools".
I think this is where your problems are arising. For consistent behaviour, I find it's a good rule of thumb to ensure all URLs begin with a leading slash. If you want to ensure all your hyperlinks generated by your ASP code are correct, use the tilde (which ASP will replace with the path to the application root folder):
<asp:Hyperlink id="Test1" runat="server" NavigateUrl="~/Tools/Default.aspx">Tools</asp:Hyperlink>
This way, it doesn't matter where your page is in your site structure, whether you're using Cassini, a web site in IIS or a virtual directory in IIS - the URL will always resolve to the correct address.
If you want to output a URL that isn't a property of a server control, use the ResolveUrl method:
Tools
Hope this helps.
By "absolute" I assume you mean they start with a "/" rather than a folder name?
If you are using the ASP.NET hyperlink control, then these will tend to modified to start at the application root.
Edit for comment
Can you give us an example of how the urls are being changed? i.e. From http://www.example.com/somepage.aspx to http://www.example.com/trackingpage.aspx?somequerysting - or is the domain changing? or something else?
You say "they still end up at the same pages" - so clearly things are working. Have you got any HttpHandlers registered in the web.config on your production servers that could be modifying the URLs for you so that they all go through some logging system? I.e. taking the response from the server, processing the resultant HTML, modifying all links - does it happen with simple anchor tags as well as Hyperlink controls?
Are you using a custom base page that is performing additional steps in PreRender or Render that's different on production to your developer machine that is changing the URLs?
Related
I have deployed an ASP.NET website on IIS 7. I was able to access my site using the URL http://**local host**/sitename.aspx and all the formatting of my pages is looking good.
But when I access the same page by using the URL http://**servername**/sitename.aspx from another system or on the same server where I have been deployed, the page formatting is not working properly.
What would be the best solution for this? Thanks
First a fall to check your Js/Css file path where you have not mention static file path with localhost name.
For more detail go to browser and browse your url and press F+12 so development tool will be open and check there for broken url.
I am not sure why you are worrying about formatting soo much. I mean formatting should not affect you much unless you use <pre> in your html.
There are ways to modify the HTTP Response Using Filters. Can you please makesure none of these filters present in your application for release mode.
Generally i use HTTP compression feature of IIS to compress my content, but in browser it looks correct to me.
The situation is the following: I created a site with Plone, developed, used, but behind a test URL. Now it has to be published, but the test URL is not appropriate and I don't want to move the site. I think, if I use a redirect, it won't be appear in the URL-bar, only in the case of site start page. Am I wrong? (The test URL should not be used, because it will be a "semi-official" site.) What do you suggest to do?
As far as I can see Plone uses absolute URLs everywhere. I can add relative URLs, but if I create a new page, a new event, etc., then they have absolute URLs on other automatically generated inner pages. Is there any way to convert these URLs to relative paths? Is there any setting possibilty where only a checkbox changes this default setting?
Plone does not store your URLs in the database. It uses the inbound host header (and any virtual hosting configuration set up with rewrite rules in Apache or Nginx) to calculate the correct absolute URL when rendering the page.
In other words - as soon as you actually point the relevant domain name to the server with your Plone instance, it'll just work.
P.S.
You should put a bit more effort into asking your question. This is just a copy and paste of a half-finished email chain where you tried to get the answer from me in private. It's not very easy to understand what you're asking.
I think what you are looking for is url rewriting to handle virtual hosting. ie to get your site to appear as if it's the root url of a domain.
This is normally done via the webserver that normally sits in front of plone. For apache, here is a howto
http://plone.org/documentation/kb/plone-apache/virtualhost
for other servers
http://plone.org/documentation/manual/plone-community-developer-documentation/hosting
You can also achieve this directly in zope (via ZMI) using something called the Virtual Host
Monster. see http://docs.zope.org/zope2/zope2book/VirtualHosting.html
PS. I don't think your question is badly worded. Plone does serve pages with a "base" tag and what appears to be absolute urls. They aren't baked into the database but it's also not obvious that the solution to getting the url you want is the VHM url syntax and a proxying frontend webserver. There is a reason why it doesn't use relative urls... which I can't remember it was so long ago.
I have an ASP.NET 4.0 application that implements URL routing. This gives me page URLs with no extension (e.g. /Articles/{title})
Some of these pages contain relative links. When I test the site from Visual Studio, relative links point to /Articles/{title}/mylink. However, when I deploy my site to a shared hosting account, the same relative link points to /Articles/mylink.
You can see the problem at http://blackbeltcoder.com/Articles/asp/creating-website-thumbnails-in-asp-net. The link to an image near the top is broken. This page worked fine when testing from Visual Studio. {title} was assumed to be a directory. But, once deployed, {title} is assumed to be the page name.
If I append "/" to the URL above, it works as expected. But how can I make sure it always works?
Can anyone help me understand this?
After extensive tests with both this website and another one that also uses URL routing, I'm finally able to define what is happening.
I'm going to describe the way this site behaves on the hosting account as "normal". It's the same way my other site works on both the hosting account AND when run on my desktop. (Although the other site doesn't use relative links this way.)
The odd case out is when I run the new site on my desktop. The browser automatically appends "/" to my routed URLs, as though they are directories.
And the reason it does this is because I have created physical directories with the same names! If I delete the physical directory, it treats the URL as a reference to a file.
So the main problem for me is that I developed the site while testing with this odd case. Therefore, the solution is either A) make sure "/" is appended to all these links so they are considered directories, or B) alter the directory structure I've designed.
I am using a master page layout etc, so all the pages have some parts of it coming from one master page or another.
Now, checkout is one of these pages, and it needs to be secure. In my master page, I am using relative path to images and Url's, and these images end up with "http". I thought that if I am using relative path, my master page AND css file automatically use https instead of http if the page is secure? Apparently it does not, when I right click on an image, it still has "http" instead of "https" ans same goes for URL path.
Check out this great article by Ned Batchelder which shows schema relative URLs:
<img src='//fast.cdn.net/pix/smiley.jpg' />
When the images come back as http are you checking this from your local dev or production? I thought I had this problem before but then realized my dev environment was always http and that the relative path would work in production because there it would be https.
Had a question from a client which stumped me.
They are using IIS 6.0 and for some reason, instead of making a normal request for a page on their server which I'll call www.domain.com/Default.aspx someone typed www.domain.com/Default.aspx/randomstuff
It seems that IIS's response was to serve Default.aspx as normal, but, as far as the browser is concerned, the path is www.domain.com/Default.aspx/ rather than www.domain.com/ and thus all relative paths to CSS, images, etc. fail
I looked at the traffic in Fiddler, and it seems that all of those image etc. requests, such as www.domain.com/Default.aspx/images/image.gif are ALSO returning the contents of Default.aspx, needless to say, not a valid image!
I don't believe they are doing anything special with URL rewriting, but just to be sure, I tried an experiment on a freshly created ASP.NET web application and the results were the same.
So what is causing IIS to pass a URL like /Default.aspx/randomstuff to the ASP.NET pipeline as a request for Default.aspx? And can it be stopped, and made to just throw a 404 as you'd expect?
This is called the PathInfo component.
You can stop like this:
if (!String.IsNullOrEmpty(Request.PathInfo)) throw new HttpException(404);
Yes, that's perfectly normal. Apache will do it too.
You can use it for routing, so you can have the URL /script.name/random/stuff instead of /script.name?page=random§ion=stuff without having to set up URL rewriting.
Naturally the browser doesn't know that script.name is the real script, that random and stuff aren't really part of the path at the server-side. So all URLs will be relative to the random directory. Normally when you are writing an application with routing, you have to make sure you use rooted or absolute URLs through rather than relative URLs, for this reason.
And can it be stopped, and made to just throw a 404 as you'd expect?
Yes, as in SLaks's answer. However it would probably be better to send a 301 to the real address without the trailing Path Info parts.