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 <https://aka.ms/AAb9ysg>
> ------------------------------
> *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