- From: <hallam@axal04.cern.ch>
- Date: Tue, 29 Nov 1994 15:30:23 +0100
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Current client support for 503 is minimal. As an example, NetScape's >response to a 503 error is to begin repeatedly resending the client's >request until it is satisfied or the client times out. If the server is >moderately busy, the client may be quickly serviced without impacting >performance from the user's or server's perspective. If the server is >heavily overloaded, a rapid, repeated resubmission of the request will only >make the problem worse. This is unacceptable, if a server is busy then that information should be returned to the user. Sending 503 should in the main be done only at the point where the server is about to collapse. One solution to this is to use a threaded server and implement a lockout, once a client recieves 503 the site is blacklisted for a period. Retry attempts in this interval would increase the blacklist period and/or return notification of a protocol violation. I like the idea of a retry in x seconds field, it would allow a server to schedule a slot where the request was guaranteed to be handled. I would like to have some control over the interpretation though. How about:- Deadtime: time[; reason=tag][; retry=policy] Where time is the deadtime in seconds, a time of 0 being an indeterminate length of time. reason tags could include: busy maintenance retry policies would include: blacklist retry attempts are now blacklisted ignore retry attempts are simply ignored lockout retry attempts are dealt with by router lockout. The final one is something added to one implementation to deal with denial of service attacks. If more than a certain number of accesses are made the system goes into `lockout mode'. This involves adding a filter record to the router to redirect packets to another server (amongst other things). We should also have a facility to allow an alternative site to be stated. This would permit rather more gracefull fallover and provide some load balancing. Phill H-B
Received on Tuesday, 29 November 1994 06:38:23 UTC