Perhaps 503 should not be viewed as such a catastrophic event. In the case of
planned maintenance it is a convenient way to announce the interruption
in service. If 503 were not viable solution, you'd see many ad hoc solutions
like presenting the same "OutOfService.html" page regardless of the client
request.
In the case of the overloaded server 503 error, there is not enough information
provided currently about when the load will be reasonable or how the client
could access equivalent information elsewhere.
>
> 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.
This is beginning to get overly complicated for the simple case of managing
the load on an over loaded server. I see my dentist every six months. Third Thursday
of the month at 4:00 PM. If I'm lucky I get a postcard in the mail as a reminder.
If I reschedule at the last minute, I get whatever slot is available at that time.
If the 503 error could schedule a reasonable "appointment" for completing the
transaction a simple list of host/time pairs could be maintained by the server.
Assuming all clients call back at their appointed times the load can be fairly
dispersed by the server. If client calls back before their scheduled appointment,
they will receive another 503 error with their scheduled time slot (or if penalties
need to be enforced move them to the end of the appointment list).
If a server scheduled appointments at one minute intervals a flood of 600
clients could be spaced out over the next ten hours (potentially prioritized
by site, client timezone, etc.). This prevents individual clients from hogging
available bandwidth and allows new clients to potentially be serviced in the slots
where blocked clients missed their appointed callback.
$.01
>
>
> 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
>