- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 26 Mar 2020 14:49:49 +1100
- To: Colm Divilly <colm.divilly@oracle.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Roy Fielding <fielding@gbiv.com>
Hi Colm, For reference, the guidance for new status codes is here: https://httpwg.org/specs/rfc7231.html#considerations.for.new.status.codes I agree this condition is potentially applicable to any resource, but it might fall afoul of another principle that we haven't written down as well -- that HTTP focuses on standardising the interface to the resource, not its implementation details (which this seems to be about). Roy might have some more thoughts here. More generally, when someone needs to convey more refined information about what caused an error, the advice we give is to put that information in the response body or a response header. Did you consider that approach? Cheers, P.S. As an aside - we discourage people from "squatting" on status codes like this because it makes it harder to use them in standards later, and they are a relatively scarce resource. Please don't use it until it has been standardised, and in the future, it's best to make proposals along the lines of "a new 5xx status code" rather than a specific number. Thanks. > On 25 Mar 2020, at 10:02 am, Colm Divilly <colm.divilly@oracle.com> wrote: > > Hi All, > for a product I help develop: Oracle REST Data Services (ORDS) [1], we provide a hosted environment where third party users can dynamically at runtime define their own REST APIs using SQL. Naturally there will be coding and runtime errors in these REST APIs. This creates a challenge for users and operators. When such a resource raises an error the only appropriate HTTP status code to use is 500 Internal Server Error. This causes confusion as it looks like there is something wrong with ORDS, where in fact there is only something wrong with the user supplied SQL. Despite explanatory text to clarify this, operators and users very often miss this distinction, and file support issues against ORDS. Further, automated tools that monitor the access log only see the 500 status code, and thus cannot differentiate between 'real' 500 errors in ORDS itself that need remediation versus 500 errors in the user supplied REST APIs that probably do not need any remediation. If a distinct status code for these kinds of errors appeared in the access log, it makes it immediately clear to both humans and tools that the error condition is caused by a user defined resource. > > We believe assigning a new HTTP status code (we chose 555 just because it is memorable) to clearly identify errors arising in these dynamically defined user REST APIs is the cleanest way to resolve this confusion. TBH not sure if this use-case is common enough to be worth standardising, so have filed this as an 'Informational' draft. Perhaps 'serverless' platforms that have a similar paradigm of third party users publishing programmatic resources to their platforms might also find this approach useful. > > Appreciate any feedback anyone may have on this approach. > > Regards, > Colm Divilly > > [1]: https://oracle.com/rest > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-divilly-status-555-00.txt >> Date: 20 March 2020 at 11:35:55 GMT >> To: "Colm Divilly" <colm.divilly@oracle.com> >> >> >> A new version of I-D, draft-divilly-status-555-00.txt >> has been successfully submitted by Colm Divilly and posted to the >> IETF repository. >> >> Name: draft-divilly-status-555 >> Revision: 00 >> Title: User Defined Resource Error HTTP Status Code >> Document date: 2020-03-20 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/id/draft-divilly-status-555-00.txt >> Status: https://datatracker.ietf.org/doc/draft-divilly-status-555/ >> Htmlized: https://tools.ietf.org/html/draft-divilly-status-555-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-divilly-status-555 >> >> >> Abstract: >> This document specifies an additional HyperText Transfer Protocol >> (HTTP) status code to indicate server error conditions arising during >> evaluation of user defined resources hosted by the server. >> >> Conventions and Terminology >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> > > -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 26 March 2020 03:50:12 UTC