I have an ASP.NET page hosted on IIS6 running in windows 2008 server. The page has two iframes both calling to pages within the same application.
When viewed in the browser (IE8, compat mode) the session gets lost within the iFrames.
IIS is setup with a virtual directory of "App", so the website is accessed via http://localhost/App.
The problem occurs if you type into the browser http://localhost/app - note the change of case.
As far as I was aware URLs are always case-insensitive, but in this instance it clearly in not. After some testing, it turns out that the important factor is that the URL typed into the Browser must have exactly the same casing as that of the URL on the iframe. Or at least the casing of the virtual directory between the two URLs.
So a simple fix is to make sure you always use exactly the same url casing in the browser as is used on the Virtual Directory, but this is a bit difficult with users.
I've thought about rewriting the URL and doing some string manipulation to make the URL of the iFrame match that of the browser, but it seems a bit hacky and potentially unreliable.
Has anyone else experienced this or is there are simply IE config I can change?
Thanks,
Urls are case sensitive. It's IIS & ASP.NET that are not case sensitive when handling request urls, but the case sensitivity you're seeing for cookie paths should be true for any browser you use. This is not something you're supposed to change.
A workaround would be to redirect requests with a wrongly cased url to the correct one. You could write an IHttpModule for this, or, if you're using IIS7, use the optional Application Request Routing module.
Related
This is a bit of a tricky question.
I am developing a .net website, and it is hosted on our own servers.
I want to redirect outside traffic to a blank "coming soon" page, while our internal network can see the content.
How do I modify the web.config to do that?
I have already tried default document settings, but it doesn't seem to accept those, and instead displays the .NET website.
Please have a look at http://www.iis.net/learn/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module. It shows how to use IIS URL Rewrite Module (which in turns writes to web.config) to handle your scenario.
We are experiencing odd behavior with our web application. If I change the URL to uppercase, or parts of it, after authenticating with the app, I then have to re-authenticate. Here's an example:
https://host.domain.com/website/asp
If I copy and paste that URL into a new tab after authenticating it will automatically authenticate and bring me to the landing page. However if I paste this into a new tab, while another tab is already authenticated:
https://host.domain.com/webSITE/asp
I have to re-authenticate with the app. (or IIS, this I'm not sure about)
This poses a problem when objects are developed without case being a consideration and I would think this behavior wouldn't be desirable. I will be reaching out to the application vendor but I'm wondering if anyone has experienced such an issue with IIS 7.
Thanks,
Max
IIS is generally case insensitive. Where sensitivity comes into play is with integrating modules. Modules like rewrite can be case sensitive. You didn't specify, but is your IIS application using rewrite at all? Also, your vendor may have controllers that are doing case sensitivity checks. But my guess would be the actual browser to be the culprit. Browsers that base cookies on the URL path can make those cookies case-sensitive. See this link for more information on users that have reported the same problem.
We have a website which has a Virtual Directory containing the secure portion of the website.
If users come to http://www.mydomain.com, they should get directed to default.aspx of the main site, but if they go to https://www.mydomain.com, they should go to default.aspx of the virtual directory.
The default page for the main site works fine, as does the secure page if I navigate to it using the full name, however I can't figure out how to set the default page for https traffic that doesn't specify a specific page.
http://www.mydomain.com - Works
https://www.mydomain.com - Page Not Found
https://www.mydomain.com/myvirtualdirectory - Page Not Found
https://www.mydomain.com/myvirtualdirectory/default.aspx - Works
What do I need to do to make links 2 and 3 load the default page show in 4?
My website is running on IIS 6.0 in Windows Server 2003
Overall, this is an anti-pattern as you state the entire behavior of the site changes based on the port. I am not stating definitively you are doing this, but consider the following:
If you are redirecting due to a user needing to see other things, you can make conditional controls that display only when in HTTPS. The same can be done for authenticated and authorized versus not.
If you are redirecting because an HTTP user needs to log in, the more consistent pattern is to have them click a log in button. And, you can force HTTPS at this point without breaking the pattern.
If you really need to redirect for some reason, there are a couple of ways of handling this:
In IIS
HTTP Handlers
URL Rewrite - requires the URL Rewrite bits for IIS 7
I imagine there are some other ways to solve this.
I finally figured out my issue. In my case, it turns out the problem was an old URL Rewrite rule I wasn't aware of that was transferring all https traffic that didn't have a file name specified to index.php, which of course didn't exist.
I found this out by viewing the IIS error logs, which was telling me the 404 was being caused by index.php
This is a follow-up on this question.
I basically have the same question as this question, but with a few differences. First of all, my url is http://site/Image/Cassandra/Image.aspx and I want to see http://site/Image/Cassandra instead. This is a routed page where I use ASP.NET routing to translate an url to the one above. But somehow, it doesn't find my page when I don't add "Image.aspx" or anything else ending with ".asmx".
That annoys me...
Since this has to run on both IIS 6 and 7, and because the administrators won't let me have access to the IIS configuration, I need to solve this from within my web application and I think web.config is the place to add the solution. But what is the solution?
(Btw, I know there is some trick with authentication and a default URL in it but that won't work in this case.)
The problem with the URL you would like to have is that IIS6 would require that a physical resource exist on disk, unless you've configured IIS6 to route all requests through ASP.NET. From your statement this would appear to not be the case.
So, assuming that IIS6 is not routing all requests to the ASP.NET pipeline, then there will be no way of providing the exact URL you are wanting.
I encountered a similar dilemma before and overcame it by modify my routes to include a dummy .aspx extension so that IIS6 would be happy. Is there a reason you couldn't modify your desired URL to contain an extension that IIS6 does route to ASP.NET?
I set up 404 handler page in web.config, but it works ONLY when extension of URL is .aspx (or other which is handled by ASP.NET).
I know I can setup static HTML page in website options, but I want to have a page.
Is there any options to assign ASPX handler page for all request extensions in IIS?
The direct question was whether or not there are options to assign the ASPX handler to all request extensions: Yes, there is. I'll discuss how to do that shortly.
First, I think the "hidden" question -- the answer you really want -- is whether or not there's a way to redirect all 404 errors for pages other than ASPX, ASMX, etc. Yes, there is, and this is the better choice if it'll solve the issue you're having.
To redirect all 404s in IIS 6, right click your web application root (whether it be its own site or a virtual directory in the main site), and choose "Properties." From there, choose the "Custom Errors" tab. Find 404 in the list and change it to the redirect you want.
Now, if that won't suffice -- and I really hope it does -- yes, you can run every page through the ASPX handler. However, doing so comes at a fairly high cost in terms of efficiency -- raw HTML/image serving is considerably faster than anything dynamic.
To do this, right click your web application root and choose "Properties." Choose the "Home Directory" tab. Click "Configuration;" a new window will pop up. Copy the path from one of the ASP.NET page serves, and then use it for a wildcard application map.
Bear in mind, again, this is the wrong answer most of the time. It will negatively impact your performance, and is the equivalent of using a chainsaw to carve a turkey. I highly recommend the first option over this one, if it will work out for you.
For information:
This is one of the several nice things that IIS7 brings - all pages are routed through the handler such that you can do custom 404s and - usefully - directory and file level security for any file (based on the same web.config stuff as for asp.net files prior to IIS7).
So notionally "use II7" is an answer (will be "the" answer in time) - but of course its not a terribly practical one if you're not hosting/being hosted on W2k8 (or higher).
The web.config can only set up errors pages for pages controlled by it's web site. If you have any other pages outside the purview of the ASP.Net application, then you set up handling for them in IIS. There's an option in there for configuring the 404 page where you can point it to your custom page.
Only other thing i can think of is passing ALL extensions to asp.net.
This way all types of files get processed by asp.net and your custom error page will work.
In the IIS application configuration, you can set a wildcard mapping (".*") to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
You can setup wild card mapping in IIS (Application configuration/Mappings/Wildcard mappings/ - just set aspnet_isapi.dll as executable and uncheck the Verify that file exists box) that will route all incoming requests to your app - so you can control the behavior directly from it.
You don't have to setup static page in your IIS application settings. Imho, you should be able to setup valid url (e.g. /error_handler.aspx) from your app that will be used as landing page in case of specific server error.
In IIS you can set a Custom Error for 404 errors and direct it to a URL in the site properties.
It shows a static html by default
C:\WINDOWS\help\iisHelp\common\404b.htm
You can change it to a relative url on your site.