W3C home > Mailing lists > Public > www-talk@w3.org > March to April 2007

Re: Best HTTP Status Code for a Redirect to a Service Suspension Page

From: Nigel Peck <nigel@miswebdesign.com>
Date: Wed, 28 Mar 2007 08:33:02 +0100
Message-ID: <460A1A2E.3050706@miswebdesign.com>
To: Damien Bezborodow <damien.b@koalatelecom.com.au>
CC: www-talk@w3.org

Since this is a temporary redirect and you don't want the redirect URL 
to be used for future requests I would suggest:

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.

AFAIK this is the standard code to use for this type of redirect and it 
is certainly in common use and well understood by most user agents.


Damien Bezborodow wrote:
> Hi everybody,
> We use a Squid Web Proxy Cache to forward suspended customers (based on
> IP) to a service suspension page if they haven't paid their bill. If
> they go to Google and are suspended they will receive a 301 Moved
> Permanently and be forwarded to our page of damnation. This is probably
> not the best status code.
> Problem is when it comes to choosing the most appropriate HTTP response
> code to send the client while keeping in mind that certain automated
> programs may be attempting to retrieve the resource (such as IM clients,
> SOAP, XML/RPC, etc).
> What would the best status code be? I have narrowed down to the following:
> 503: Service unavailable. Mainly used if the server is overloaded or
> undergoing maintenance. (This is strictly a server error.)
> 307: Temporary redirect (to content that is supposedly available at a
> different URI).
> 403: Forbidden. The server understands the request but is refusing to
> fulfil it. Authorisation will not help and the request should not be
> repeated.
> So, which is best in this situation?
> Regards,
Received on Wednesday, 28 March 2007 07:33:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:06 UTC