vanity url technique. call for critiques

Results 1 to 4 of 4

Thread: vanity url technique. call for critiques

  1. #1
    Join Date
    Dec 1969

    Default vanity url technique. call for critiques

    Like alot of asp/.net web apps, My site&#039;s urls are generated with the following syntax...<BR><BR><BR><BR>Until now, I&#039;ve put off dealing with this eyesore on the face of web usability in light of larger priorities. However, the upcoming release of our product is championing web standards, xhtml, css and .NET. Therefore we had to do something about the dynamic url situation. Not being able to grasp how to effectively implement a URL rewriting scheme, I think I&#039;ve found a fairly simple solution that addresses most, but not all, of the issues. I now create my urls in the following form...<BR><BR><BR><BR>which to the average user is much more meaningful than the alternative, not to mention its more future proof for the site owner since it does not favor a particular app server (no file extensions, for example). It also allows me to mask the app server&#039;s file extensions (however meager in terms of secure that is, it too is better than the default.aspx alternative).<BR><BR>The only thing that is missing with this technique is the ability to "hack" the url to move to a given section. For example, one might think that they could chop off "Child_of_About_Us/Grandchild_of_About_Us" and be directed to the "About Us" page. However, since my page engine loads pages based on the id parameter alone, this is not possible without some sort of rewriter code. I welcome some discussion on how to make that possible and the relative merits of this technique over others.

  2. #2
    Join Date
    Dec 1969

    Default RE: vanity url technique. call for critiques

    I&#039;ve just begun to dive into this myself. In our case, I think we&#039;re going to use something like ISAPI rewrite as a middle-man. That way there&#039;s a clean disconnect between the public user-friendly/readable/permananent URLs and the backend as-messy-as-we-want-to-get query strings. <BR><BR>This will most likely be the &#039;first phase&#039; solution after which we&#039;ll go back and when we do version 2 of our site, probably try to come up with a more formal rewriting engine of our own to handle the main strings, and then just append the random non-hackable-worrying strings at the end of that.<BR><BR>WARNING: I&#039;m a newbie to .net, so take the above with a grain of salt ;o)<BR>

  3. #3
    Join Date
    Dec 1969

    Default There was a thread on this...

    ...not long ago. URL Rewriting. And I think there&#039;s an MSDN article on it.<BR><BR>.NET makes it pretty easy to do and can be pretty flexible.<BR><BR>I read the article but didn&#039;t bookmark it. Search around, you should be able to find it.<BR>

  4. #4

    Default RE: There was a thread on this...

    The ever helpful and prolific Scott M. wrote an article:<BR><BR><BR>There is one potential issue, he uses a custom form class which may not play nice with visual studio.<BR>For this and other reason, that little part is not an option.<BR><BR>I working out some stuff with the URL mapping in MCMS, it has a similar issue when you post back<BR>The built in work-around uses some javascript to fix the action when you postback. Said javascript causes serious problems with certain browsers. <BR>Without the script, postbacks go to the ugly URL.<BR><BR>I might have a complete aanswer monday...<BR><BR><BR><BR>When I was testing in a plain OnPreRequestHandlerExecute didn&#039;t always get called, I would get 404s. <BR>MCMS has its own way of dealing with pages that don&#039;t exist if they correspond to postings.<BR>The key call is Context.RewritePath, but it&#039;s effect is not the same if it is called in _BeginRequest :( <BR><BR>It might be as simple as adding a RewritePath in Scott&#039;s version, I will have to try it after getting the MCMS one fixed. <BR><BR><BR><BR>....long post eh :)<BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts