RE: A few semantic points for HTTP/1.0 draft

Bob Denny ([email protected])
Tue, 29 Nov 94 11:30:29 PST


>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.

This is how my servers (16- and 32-bit Windows) work.

>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.

This is a fabulous idea. I will consider adding this to the 32-bit server.

>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.

I heartily vote for this proposal.

-- Bob