Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Jan 06, 2010

"Your Site Is Unavailable" HTTP Response Code

We typically apply an iRule to our VIPs which sends a HTTP::redirect to a friendly "your site is not available" page when the LB_FAILED event is triggered. And I haven't actually verified this but according to the doc, the HTTP::fallback statement and the Fallback Host field in the HTTP profile both return a 302 response code. In all of these cases when the browser asks for the site unavailable page, the web server responds with a 200 error code when it returns the site unavailable content.

 

 

We have a Google Search Appliance crawling one of our VIPs, and it follows the 302 redirect and indexes the site unavailable content when the LB_FAILED event is triggered.

 

 

To work around this, we obviously could return a 404 with some content. However the counter-argument is that this behavior does not comply with HTTP standards.

 

 

I'm interested in getting your thoughts.
config
design
  • The_Bhattman's avatar
    The_Bhattman
    Icon for Nimbostratus rankNimbostratus
    Jan 06, 2010
    You could certainly set it up so that it performs a 404 against the Google Search Appliance, but no one else would see that.

     

     

    my 2 cents

     

     

    Bhattman
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jan 06, 2010
    Hi smp,

     

     

    How about using HTTP::respond with cache control headers in LB_FAILED?

     

     

    HTTP::respond 302 Location http://maintanence.example.com Cache-Control No-Cache Pragma No-Cache

     

     

    You could also set caching headers on the maintenance host or page to prevent responses from being cached.

     

     

    Aaron
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Jan 09, 2010
    Yes, you are both right. In fact, there are many other ways we could resolve this too. But I find it surprising that more people haven't run into problems with this. Would it bother you if we returned a 500 with some content? (sorry, I mean to use 500 and not 404 in my orig post)... Or is does this strike you as irrelevant and something I should just get over?
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jan 09, 2010
    Reading RFC2616 for the 302 status, it looks like the response should not be cached unless the server explicitly sets a cache-control header telling the proxy to do so:

     

     

     

    ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

     

     

    10.3.3 302 Found

     

     

    The requested resource resides temporarily under a different URI.

     

    Since the redirection might be altered on occasion, the client SHOULD

     

    continue to use the Request-URI for future requests. This response

     

    is only cacheable if indicated by a Cache-Control or Expires header

     

    field.

     

     

     

     

    I assume LTM does not set any cache-control headers in the fallback response. If that's true, why did the Google Search Appliance cache the fallback host 302 response?

     

     

    I think sending a 302 with cache-control headers set appropriately is a clean solution in terms of the client receiving a correct response code and any caching proxies not caching the temporary response.

     

     

    Maybe the cache-control: no-cache header is something that LTM should set by default when the fallback host is used if it turns out that some proxies incorrectly cache the response with no cache-control header.

     

     

    Aaron