Forum Discussion

Brian_107072's avatar
Brian_107072
Icon for Nimbostratus rankNimbostratus
Jan 24, 2011

HTTP::respond 408 content not working for Firefox

Greetings fellow iRule coders,

 

 

We want our BigIP to display status pages, either intercept status codes form servers or serve status pages for specific requests.

 

 

We have it all working except for the 408 status code. When we serve a 408 status code Firefox displays "The connection was reset" while IE displays the 408 status page. Any idea why this happens with firefox and how to work around it?

 

 

We are on BigIP 9.4.8

 

 

Example of the iRule:

 

 


  switch -glob $respStatus {    
    400    -
    401    -
    403    -
    404    -
    408    -
    500    -
    503    { HTTP::respond $respStatus content $err($respStatus) }
  }

 

 

The variable "$err($respStatus)" contains the html to be displayed as the status page.

 

 

I have tried duplicating the 408 html with the 404 and that made no difference. So I have ruled out the actual html as the culprit. I assume it has something to do with how the browser handles a 408 status code.

 

 

Debugging shows that firefox seems to go into a loop requesting the same page 10 times then it displays the error page. IE requests the page once and acts as expected.

 

 

Any assistance would be appreciated.

 

application delivery
dev
devops
iRules

5 Replies

Sort By
  • Chris_Miller's avatar
    Chris_Miller
    Icon for Altostratus rankAltostratus
    Jan 24, 2011
    Googling "firefox http 408" shows someone else as having the exact same problem (via experts-exchange) where firefox displays a connection reset. I suppose you could rewrite the 408 as a different response code and see whether that helps?
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Jan 25, 2011
    It indeed sounds like a bug or questionable behavior in FireFox that is preventing you from displaying the desired status code (408: Request timed out) page. If you want to go the rewrite route it shouldn't be terribly hard, you'd just have to change the switch a little bit:

     

     

    
  switch -glob $respStatus {    
    400    -
    401    -
    403    -
    404    -
    500    -
    503    { HTTP::respond $respStatus content $err($respStatus) }
    408    { HTTP::respond 400 content $err($respStatus)}
  }

     

     

    This would of course make your 408s return as 400s, but the user would get the appropriate message since you're custom formatting that anyway. The browser would just read the response as a 400 and likely stop giving the error you're seeing.

     

     

    I'm not sure if that's a viable solution or not, but it would likely work around the problem.

     

     

    Colin
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Jan 25, 2011
    It indeed sounds like a bug or questionable behavior in FireFox that is preventing you from displaying the desired status code (408: Request timed out) page. If you want to go the rewrite route it shouldn't be terribly hard, you'd just have to change the switch a little bit:

     

     

    
  switch -glob $respStatus {    
    400    -
    401    -
    403    -
    404    -
    500    -
    503    { HTTP::respond $respStatus content $err($respStatus) }
    408    { HTTP::respond 400 content $err($respStatus)}
  }

     

     

    This would of course make your 408s return as 400s, but the user would get the appropriate message since you're custom formatting that anyway. The browser would just read the response as a 400 and likely stop giving the error you're seeing.

     

     

    I'm not sure if that's a viable solution or not, but it would likely work around the problem.

     

     

    Colin
  • Brian_107072's avatar
    Brian_107072
    Icon for Nimbostratus rankNimbostratus
    Jan 25, 2011
    Chris & Colin,

     

     

    Thanks for your responses. They were quite helpful. Rewriting the status as a 400 sounds like a good option. We'll give it a go in our test environment.

     

     

    Thanks again,

     

    --Brian