- From: Asveren, Tolga <tasveren@rbbn.com>
- Date: Tue, 1 May 2018 11:00:30 +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: <CY4PR03MB3160997E2A79AC0433B62031A5810@CY4PR03MB3160.namprd03.prod.outlook.com>
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. Thanks, Tolga From: Julian Reschke <julian.reschke@gmx.de> Sent: Tuesday, May 1, 2018 6:19 AM To: Asveren, Tolga <tasveren@rbbn.com>; Martin Thomson <martin.thomson@gmail.com> Cc: 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 Tuesday, 1 May 2018 11:01:05 UTC