About the / question

7 Comments

• Well, I havent tried this, but in theory, we could write a checker function to determine if the URL the user typed ends with a '/' character, and if it does, then we redirect it to the same url, without that char.
  
  
  
  This would be a temp. fix...but it would be a pain in the ass to add that to every single page.
  

• Sure Gabriel but this should be fix at the source. The question is to determine if it's an IE problem (seems not to be) or a .Net or IIS ?
  

• Have you raised this with MS support? I'm guessing what will happen.
  

• Two things: you assume too quickly that users are techies, no they can have a / and if nothing tell them the page that they see is wrong, they wuill go elsewhere thinking the web design is very poor. Or sometimes complaining, I saw this reaction many times believe me.
  
  The second point is absolutly no way I am going to include absolute links in my sites. I am a big supporter of the relative fan club. Why? Because I have to deal with 2 or three servers for the same projects, and I am not going to play the fool wasting my time to change at every deployment the name of the server. By the way, 99% of the sites using .aspx have the same issue. So why it should be to the developer to turn around a bug who annoy the majority of them ?
  
  

• Guys,
  
  
  
  I don't really see how this is a bug. Both ASP.NET and IE are doing exactly what you're asking them to do. It is not IE's fault that ASP.NET recognizes trailing slashes and I don't see how IE would be able to determine whether it is displaying a default document for a directory or a page with trailing slashes. Hard-coding some special handling of ".aspx" pages in IE is just asking for trouble.
  
  
  
  I second Johnny's opinion that such occurences of users mistyping the URL would be extremely rare to be concerned about.
  
  
  
  However, if you are, the simplest fix is to add this code to the Application_BeginRequest method of Global.asax.cs:
  
  
  
  if (Request.PathInfo.Length > 0)
  
  {
  
  Response.Redirect(Request.FilePath + Request.Url.Query);
  
  }
  
  
  
  And you should be all done and be right back on your merry way.
  
  
  
  

• Well...now that there's a view of it being a feature and a bug. I dont know since i havent used url rewriting at all....but i do have to agree that, it will not be frequent that a user will make the mistake of MANUALLY typing an ending slash at the end of the document. The problem is when your own code/links point to that.
  
  
  
  I read in some CGI book a long time ago, that the correct way to write an hyperlink when pointing to a domain only was to end it with a slash. I cant remember the reason, it was something about a single ip hosting different websites..
  
  
  
  There must be a way the ASP.NET team can work it out without dropping the feature Snorrk talked about.
  
  
  
  And lets hope they fix it quick cause we all know how bad aspx pages look without their CSS styles. Btw, I also agree on not using absolute paths instead of relatives.....it kills re-usability.
  

• [Same comment I posted on your previous post, just to make sure that everyone that's following this up, can read this]
  
  
  
  Raymond is right on the topic. Now, this does not happen with ASP, since the ASP ISAPI DLL does not allow this kind of thing. Same for HTML, except that the ASP ISAPI DLL is not called for this but that it's handled by IIS itself (in a standard environment).
  
  
  
  Now, how can you resolve this? The ASP.NET ISAPI is configured not to check if the file exists. Go to the application settings of your webapp (on the virtual folder in the IIS MMC, click properties, click configuration on the default tab). There you'll find a tab "Mappings" and a list of all extentions and the ISAPI that handles them. For security reasons the list should be as short as possible (read: needed), but this is another topic. Now, find the ".aspx" extention and click "Edit". Now you can check the checkbox "Check if file exists". If you do this, IIS will check if a file actually exists before it sends the request to the ISAPI handler. So, in this case, IIS will check if your "page.aspx/" exists. Since it doesn't, you will get a 404. Please note that this can have an impact if you want to work with "virtual files", i.e. requests to files that do not really exist but that are handled correctly by a HTTP Handler.