Re: New version of HTTP response 420 Requester Impaired

I’m also in the “403 probably covers this scenario” camp, especially since I also feel like the suggested semantics is more theoretical than practically useful for a while still. I also fail to see why RFC 9457 isn't sufficient to explain why the request was rejected.

If we need a media type-agnostic mechanism to explain the details of why the request was rejected, I would rather see that we explore the idea of making the semantics of RFC 9457 available and suitable for use in a header, rather than inventing a new specific header for just this particular use case.

https://github.com/ietf-wg-httpapi/rfc7807bis/issues/35
https://github.com/ietf-wg-httpapi/rfc7807bis/issues/56
https://github.com/ietf-wg-httpapi/rfc7807bis/issues/67

--
Asbjørn Ulsberg    -=|=-    asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
On 13 Dec 2023 at 20:22 +0100, Richard Roda <richard_roda@hotmail.com>, wrote:
> Exactly the same reasoning I came up with.  Since 403 Forbidden already means that the server understood the request but refuses to authorize it, I think it is an excellent candidate to have some kind of extension such as response headers detailing that the refusal to authorize it is because of a policy violation such as erratic requests as well as information on how to signal remediation.
> From: Rory Hewitt <rory.hewitt@gmail.com>
> Sent: Wednesday, December 13, 2023 1:53 PM
> To: Richard Roda <richard_roda@hotmail.com>
> Cc: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>; ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> Subject: Re: New version of HTTP response 420 Requester Impaired
>
> Hey Richard,
>
> Given Glenn's comments about the use of a response code (whether 420 or an existing one) and my concerns about how a server would know when a client had stopped being impaired, I think any 420 response code would need to be matched with a "Retry-After" response header, e.g.:
>
> HTTP/1.1 420 Requester Impaired
>   Retry-After: 30
>
> which would tell the client that any request made within the next 30 seconds will be denied with another 420 (without the Retry-After value decremented). Of course, that's not to say that the next response 31 seconds later won't still be impaired!
>
> But then, there's no need for a 420 - just a 400 with the Retry-After header, and that already exists...
>
> So the benefit of adding the 420 is to let the client know that the reason it's getting an error  is because it's not making sense. Which is maybe a benefit over a 400 response, especially for AI clients.
>
> Rory
>
>
>
>
> On Wed, Dec 13, 2023 at 5:22 AM Richard Roda <richard_roda@hotmail.com> wrote:
> > I see why Spring uses the 420 error code for Method Failure.  It's specified in a draft of the WebDAV protocol.
> >
> > Perhaps an error extension to 403 is more appropriate.
> >
> > https://datatracker.ietf.org/doc/html/draft-ietf-webdav-protocol-05#section-10.5
> >
> > Get Outlook for Android
> > From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
> > Sent: Wednesday, December 13, 2023 5:13:06 AM
> > To: Richard Roda <richard_roda@hotmail.com>
> > Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> > Subject: Re: New version of HTTP response 420 Requester Impaired
> >
> > On Wed, Dec 13, 2023 at 04:38:23AM +0000, Richard Roda wrote:
> > > https://datatracker.ietf.org/doc/draft-richardroda-420requesterimpaired/
> > >
> > > Thanks for the feedback on this.  I have an update for the draft that addresses the technical shortcomings of the original. Specifically,  it defines how an Impaired requester can assert it has been remediated.
> > >
> > > This code is primarily intended to be used in a system-to-system scenario.  Specifically, as a way to deal with the "AI gone rouge" scenario that is possible when a LLM hallucinations get acted upon.
> > >
> > > There is a fundamental difference between a LLM requester and other misbehaving automations such as webcrawlers.  The LLM is an actual user of the system performing tasks autonomously for its ultimate human user.  This error code attempts to define a framework to signal an LLM that it's outside of its guardrails and a mechanism for it to recover.
> >
> > My understanding is that you are proposing a new HTTP status code because
> > the new status code indicates
> > a) a specific policy has been violated and that specific policy
> >    rendered a judgement of "requester impairment"
> > b) out-of-band action is required before the server will accept further
> >    requests, and that out-of-band action required involves informing the
> >    server or another trusted third party.
> >
> > The new status code seems to be to indicate that once the out-of-band
> > action has been taken, the request might be submitted as-is, without
> > any changes.  This is in contrast to a 4xx status code such as
> > 414 URI Too Long, which indicates that the client should not resubmit
> > the request as-is since changes to the submitted request are required.
> >
> > If the scope of your propsal is expanded beyond the specific policy
> > judgement of "requester impaired" to be more general as "policy
> > rejection plus an action that involves contacting the server in a
> > semi-defined way", then I think a new 4xx HTTP status code might have
> > some merit.
> >
> > Then again, does there need to be a new HTTP status code assigned (420),
> > or could additional header(s) be added to responses with an extended
> > error message and remediation link?
> >   HTTP/1.1 400 Bad Request
> >   error-extension: ...
> >   error-action-required: ...
> >
> > Practically speaking, the "action-required" might tend towards needing
> > a new HTTP status code so that the awful "friendly" error messages that
> > some browsers use to hide any actual useful information might see the
> > new HTTP status code and do something more useful than frustrating users
> > and enraging those who try to help those users since there is a lack of
> > useful, actionable information.  Then again, a new standardized response
> > header might also work for that, too.
> >
> > Cheers, Glenn
> >
> >
> > Here's one example of error extensions, even though I have other strong
> > criticism (off-topic) for many other parts of MS-WDV:
> > [MS-WEBDAVE]: Web Distributed Authoring and Versioning Error Extensions Protocol
> > https://learn.microsoft.com/en-us/openspecs/sharepoint_protocols/ms-webdave/9fb175f3-f063-4389-a959-4457692e4b49
> > 2.2.2 Extended Error Handling
> > https://learn.microsoft.com/en-us/openspecs/sharepoint_protocols/ms-webdave/fd085a2b-c812-4d7c-a28c-2cab5dc34747
> > 2.2.3 Currently Defined WebDAV Extended Errors
> > https://learn.microsoft.com/en-us/openspecs/sharepoint_protocols/ms-webdave/bda6b27f-b0c2-4310-bb79-1f9a7caeb426
> >
> > Aside, with regards to status code 420, there is some more history:
> > https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
> > Unofficial codes
> >   420 Enhance Your Calm (Twitter)
> >     Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.  The phrase "Enhance your calm" comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.[citation needed]
>
>
> --
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt