W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Fwd: New Version Notification for draft-divilly-status-555-00.txt

From: Colm Divilly <COLM.DIVILLY@ORACLE.COM>
Date: Tue, 24 Mar 2020 23:02:38 +0000
Message-Id: <84C127AC-BA21-4CD8-9F79-8920ADE5BA4C@ORACLE.COM>
To: ietf-http-wg@w3.org
´╗┐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



Received on Tuesday, 24 March 2020 23:02:59 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 24 March 2020 23:03:01 UTC