W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

RE: A few semantic points for HTTP/1.0 draft

From: <hallam@axal04.cern.ch>
Date: Tue, 29 Nov 1994 15:30:23 +0100
Message-Id: <9411291430.AA18374@dxmint.cern.ch>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:08 EDT