Re: New version of HTTP response 420 Requester Impaired

I like the idea of making a "policy violation" registered problem type per section 4.2 of RFC 9457.

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
Sent: Thursday, December 14, 2023 8:44:55 AM
To: Rory Hewitt <rory.hewitt@gmail.com>; 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

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<mailto: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<mailto:gs-lists-ietf-http-wg@gluelogic.com>>
Sent: Wednesday, December 13, 2023 5:13:06 AM
To: Richard Roda <richard_roda@hotmail.com<mailto:richard_roda@hotmail.com>>
Cc: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org> <ietf-http-wg@w3.org<mailto: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