views:

333

answers:

7

I was just told that I might have to work on a project where i will be working with ASP.NET 3.5 and C#. Someone in our team said that we should change all the pages to HTML when we publish the site. So instead of having www.test.com/Page.aspx we will have www.test.com/Page.html

So what i would like to know is:

A.) How can this be done and with what tool?

B.) Why should this be done and what can we benefit from it? (Was told to prevent hackers to get it)

C.) Is this recommended?

Thanks in advance.

A: 

B) The only reason I can think of to do this, is to hide an obvious identifier of the server side technology that you are using. However, this is security by obscurity and that should never be your only and primary security measure. If you want to do it for aesthetic reasons or something, fine, but don't expect it to hold off a determined hacker.

Daan
In general I feel security by obscurity does have a place within an overall security scheme.
Howard May
@Howard - You are right, it does have its place, so maybe I put my answer a bit too strongly. But in my experience, some developers rely too easily on security through obscurity as the *only* security measure, and that really is bad practice.
Daan
@Howard - Updated my answer in response to your comment.
Daan
+9  A: 

A) You do it by changing Web.config:

<system.web>
    <httpHandlers>
        <add verb="*" path="*.html" type="System.Web.UI.PageHandlerFactory"/>
    </httpHandlers>
</system.web>

B) The reason would be to prevent viewers from knowing what runtime is behind the site, but in most cases with ASP.NET, it's easy to recognize from its additions to the HTML (such as view state etc.)

C) It's up to you really, I wouldn't say it's good or bad.


In response to your comment below:

It's possible that you need to specify a buildHandler as well:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="true">
      <buildProviders>
        <add extension=".html" type="System.Web.Compilation.PageBuildProvider" />
      </buildProviders>
    </compilation>
    <httpHandlers>
      <add verb="*" path="*.html" type="System.Web.UI.PageHandlerFactory" />
    </httpHandlers>
  </system.web>
</configuration>
Blixt
There are some other items inside my <httpHandlers>, must i delete them?
Etienne
Nope, this will add the handler to the others. *.aspx pages will still work, but you can name them *.html instead and they will still work.
Blixt
Let me get this right. You saying i must include that Handler in my Web.config. And then go to my page and just rename my Page.aspx to Page.html?
Etienne
Yup, that ought to work.
Blixt
I did that....My project run, but nothing get's displayed..........
Etienne
Ah... See my edit above.
Blixt
Thanks buddy! It worked!
Etienne
+2  A: 

I was a contractor on a large motoring site, and we were asked to not dislpay any file extensions at all, because the company (a very very large news agency) didnt want to appear to pick one technology above another to its investors and suppliers - it was purely a business desicsion, not a techincal or a security by obscurity attempt.

pzycoman
A: 

A: With MVC over ASP.NET you can create a route which you can map to virtually any type of URL you want.

 routes.MapRoute("Route1", "Foo/{Cat}/{SubCat}/{Record}.html", new { controller = "Foo", action = "Record" });
Si Gardner
+1  A: 

C) There's no recommendation for or against it, but you should be careful when you make *.html passed to ASP.NET because it will cause additional overhead when what you actually want is just static HTML page (no server side processing).

Adrian Godong
A: 

It could potentially be for SEO reasons. Google doesn't like urls like this:

longurl.com/index.aspx?id=1&time=3&this=2

It might be that the member of the team wants to route the url's differently so that Google is more likely to pick them up.

longurl.com/index/1/3/2.html

Don't ask me why google prefers this, but it just does. If I were to have stab though, it likes to know that content is there. The top link is obviously dynamically generated and not always likely to be there.

Of course if this is for an internal web-app, it could be to try and prevent the users from messing about with the URL string and breaking the site.

EDIT: In summary, as can be seen by the above answers too, there are potentially more than one reason for this. Security from hackers seems like a pretty poor reason, however. If the code is robust enough, no matter the form of the URL it would be safe.

JonB
Google does value query string parameters lower than the path in keyword relevancy, but the extension doesn't really matter unless it's part of the search query. If routing, one might as well skip the extension altogether, unless several content types are being served (`.../page.json`, `.../page.html`, `.../page.xml`, and so on.)
Blixt
But even if routing different types, you still don't necessarily have to put the extension specifically.For example:longurl.com/blog/rss2/longurl.com/blog/atom/longurl.com/pagename/json/Are all fairly self explanatory what they do or would produce.
JonB
True. I'd probably still prefer using the extension for dividing types though, because 1) I prefer to represent pages as files in the path, not directories and 2) nesting the path one more level can cause issues if the page has relative URLs.
Blixt
+4  A: 

B) C)

If the urls are public, you should put in url's relevant information, and things that are unlikely to change in the next 10-20 years (or more..), and that would be:

  • a short description about the presented page

These things may change over time:

  • ids - if you port the data to other systems
  • .html .php .jsp .do .aspx if you change the technology
  • /controller/view/main if you rearrange the structure of your site

If the urls are private, it doesn't really matter how you construct them, as long as it helps your application.

Mercer Traieste
+1: Very valid points. URLs should uniquely identify the content and nothing else. But in 20 years I imagine we won't see URLs as we do today, but for now, let's assume we do =)
Blixt