Forum Discussion

6 Replies

  • when HTTP_REQUEST {
      set host [HTTP::host]
      set path [HTTP::path]
    }
    when HTTP_RESPONSE {
      if { [HTTP::status] eq "404" } { HTTP::redirect "https://${host}/my404page?url=${path}" }
    }
    
  • that assumes of course you have a my404page page defined to respond. You could define this in an iRule by uploading the source to an iFile (named my404page_html in this example) and then respond to requests with it:

    when HTTP_REQUEST {
      set host [HTTP::host]
      set path [HTTP::path]
      switch $path {
        "/my404page" {
          HTTP::respond 200 content [ifile get "my404page_html"]
        }
      }
    }
    when HTTP_RESPONSE {
      if { [HTTP::status] eq "404" } { HTTP::redirect "https://${host}/my404page?url=${path}" }
    }
    
  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus

    @Jason: wouldn't it be much better to use Status Code 404 for the HTTP::respond? (instead of the 200 OK)

     

  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account

    It depends on your desired effect. Some clients prefer receiving a 200 status with the customized page, some want to be sure they're still getting the proper 404 code to trigger any appropriate monitoring or the like that they have happening synthetically. I've seen both as applicable, depending on deployment.

     

    Colin
  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus

    One of the problems is that 200s could be indexed by search engines - not a great thing to have happen.

     

    Regarding 404s, I generally also check for 403s, since a request for a non-existing resource that ends in a "/" can be interpreted by the web server as a directory request and thus result in a 403. Technically they're not the same, of course, but to an end user they're the same.

     

  • understood on the indexing, but some browsers have default pages for errors and will not display your custom 404 page without some work.