W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

RE: draft-asveren-dispatch-http-overload

From: Asveren, Tolga <tasveren@rbbn.com>
Date: Sun, 6 May 2018 19:46:15 +0000
To: Julian Reschke <julian.reschke@gmx.de>, Martin Thomson <martin.thomson@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <CY4PR03MB316006C17D5AC3D81F54850BA5840@CY4PR03MB3160.namprd03.prod.outlook.com>
To regroup:

i- Is there any existing mechanism (503 with Retry-After does not provide a satisfactory solution) which would address the server/application overload problem? AFAICT the answer is “No” (but I am ready to be corrected)

ii- (Assuming that “No” holds good for i-) I am planning to update the draft with explanations about:

  *   Why 503 with Retry-After is inadequate
  *   That the intent is not to prevent attacks from malicious users
  *   The scope is server/application overload

Any other suggestions/feedback are welcome.


From: Asveren, Tolga
Sent: Tuesday, May 1, 2018 7:00 AM
To: 'Julian Reschke' <julian.reschke@gmx.de>; Martin Thomson <martin.thomson@gmail.com>
Cc: ietf-http-wg@w3.org
Subject: RE: draft-asveren-dispatch-http-overload

Agreed that it could be server or the application or the resource (at least theoretically and maybe also in practice). This draft is about server/application overload cases. For real-time application use, these need to be addresses in a satisfactory way for enabling better response times once they happen IMHO.

So, maybe a new parameter indicating the nature of the overload could be useful. Any thoughts on that?

And my apologies for not being clear about the terminology causing confusion.


From: Julian Reschke <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>
Sent: Tuesday, May 1, 2018 6:19 AM
To: Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>>; Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
Cc: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
Subject: Re: draft-asveren-dispatch-http-overload

NOTICE: This email was received from an EXTERNAL sender

On 2018-05-01 11:41, Asveren, Tolga wrote:
> I certainly will include these explanation, and more about a few other
> issues, in the next version of the draft. My initial goal was to get
> some initial idea/feedback from other folks.
> Regarding interpretation of 503: I think it is quite clear, at least
> IMHO, based on RFC2616 that it indicates the status of the server in
> general not just for a single request:
> *10.5.4 503 Service Unavailable*
>    The server is currently unable to handle the request due to a
>    temporary overloading or maintenance of the server. The implication
>    is that this is a temporary condition which will be alleviated after
>    some delay. If known, the length of the delay MAY be indicated in a
>    Retry-After header. If no Retry-After is given, the client SHOULD
>    handle the response as it would for a 500 response.
> I also never saw it being interpreted/used on “per request” basis in
> practice.
> ...

RFC 2616 is irrelevant. RFC 7231 says:

> The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field (Section 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request.
> Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.

That IMHO leaves the nature of the overload open; it could be the server
itself, a specific service, or just one resource.

Best regards, Julian
Received on Sunday, 6 May 2018 19:46:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC