Forum Discussion

johndegern_4568's avatar
johndegern_4568
Icon for Nimbostratus rankNimbostratus
Apr 30, 2010

Forcing lowercase only works the first time

So I am trying to force ALL HTTP requests to lowercase and i'm using this rule:

 

when HTTP_REQUEST {

 

HTTP::path [string tolower [HTTP::path]]

 

}

 

 

It works on the host and it works if I manually enter www.domain.com/Url.aspx but if I click through any links it allows the Mixed case again.

 

 

Whiskey tango foxtrot?!?

8 Replies

  • Hi John,

     

     

    The iRule is going to rewrite the path before the requests are sent to the pool members. It won't affect the URLs in the response content sent to clients. So when a client clicks on a link or follows a redirect, the address bar will show whatever case the application used in its references to itself. The requested path seen by the web application will always be in lower case.

     

     

    It would be quite resource intensive to try to parse and rewrite every path from response payloads (and to a lesser extent, the response headers). If you really wanted to do this, you would need to figure out a regular expression which would match the paths. You could then use a stream filter and STREAM::expression based iRule to do this.

     

     

    Aaron
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Apart from asthetics, is this going to matter though? Domain names are case insensitive, so the request will always come back to the correct VS... When the request does come in, he iRUle will fire and you'll rewrite the URI to lowercase before the request is passed through to your backend server.

     

     

    I've got to ask though... Why is this necessary? (Sorry, curiosity only)

     

     

    H
  • The first part of a URL is universally case insensitive [HTTP::host], but the URI [HTTP::uri]can be case sensitive depending on the operating system hosting the website.

     

     

    Windows (IIS) - links will get to your pages regardless of capitalization (or lack of it).

     

     

    Linux/Unix - if your site is hosted in a Linux/Unix environment and you rename your page www.example.com/PopularPage.htm to www.example.com/popularpage.htm, you could suddenly find yourself facing a drop in traffic as people clicking on the search engine link get a 404 error telling them that the page cannot be found.

     

  • The company I am doing this for hired a SEO consultant to give them recommendations. This is one of those recommendations. In the infinite wisdom of the developers they coded files using mixed case throughout the entire site. This is giving duplicate pages in the Page Ranks of multiple crawlers.
  • I think that the iRule is probably working, as this iRule is set to process everything. If you are using IIS, then it really doesn't matter because it really doesn't care, but you can still use the iRule to correct the case as it is presented to the server.

    As Hoolio pointed out, it would be a resource intensive process to rewrite everything within the website, as well as the contents of the [HTTP::header "Location"] where any website Hyperlinks or Redirects would be put to transport back to the requestor.

    Your best bet is going to be that the iRule is working on all incoming traffic, and then advise the developers to start using lower case for everything.

    How to Verify:

    
     when HTTP_REQUEST {
    HTTP::path [string tolower  [HTTP::path]]
    log local0. "String to Lower iRule: [HTTP::path]"
    }
    

    The "log local0. "String to Lower iRule: [HTTP::path]"" will log the [HTTP::path] to the LTM Log.

    Apply the iRule to a Virtual Server that you want to test.

    SSH into the F5 and locate the LTM Log:

    cd /var/log

    Set continuous read from the LTM Log:

    tail -f ltm

    Do your testing and every time the iRule fires you should see the entry in the log and it should show the URL you access after it has be processed by the iRule (everything should be lower case).

    NOTE: This iRule will not change the URL displayed in the Browser. It will only change what is being sent to the server.
  • It's possible to do this in an iRule, but it could get very complicated and resource intensive. If you can't change the pages themselves, you could try rewriting the URLs in the HTML responses on the IIS servers. I think IIS URL rewrite plugin should support this:

     

     

     

    http://www.iis.net/download/URLRewrite

     

     

    Easily replace Web application URLs to produce user and search engine friendly results

     

     

    URL Rewrite permits Web administrators to easily replace the URLs generated by a Web application in the response HTML with a more user friendly and search engine friendly equivalent. Links can be modified in the HTML markup generated by a Web application behind a reverse proxy. URL Rewrite makes things easier for outbound response content and headers rewriting with outbound rewrite rules that work with HTTP request and response headers and with IIS server variables.

     

     

     

     

    Aaron
  • That would be great, if only they offered 2.0 for IIS 6.0. I'm making them go back through the code and do it the right way. There is no reason to fit a square peg in a round hole just cause they hired bad developers.

     

    I do use the URL Rewriter in a few environments and it's not bad for spcific uses. Lets face it though, why bring traffic in to a web server just to have that web server send it some where else. Not to mention that it creates a bloated IIS configuration and rule are managed through an unencrypted xml file at the root of the application. Just sayin.

     

     

    Moral of the story, follow "best practice" and you won't have to try to improvise later.