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