3 ms·

An HTTP Status Code to Report Requester Impairment

14 points by healsdata 3y ago

cratermoon 3y ago
"420 Requester Impaired" I thought this was an April 1 RFC.
- openthc 3y ago
  I'm here for the 420 jokes. This one wouldn't be good even on April 1st (or 20th)
tooker 3y ago
I read the entire thing and still can't tell if this is a joke.
- Waterluvian 3y ago
  My most charitable interpretation is that this is attention-seeking by the author. It’s not a good idea. It’s not funny.
sgammon 3y ago
I hope this is a joke, otherwise, I don't understand the pejorative use of "420" for this status code. Cannabis consumers would really love the dignity of being treated like any old alcoholic. /s
- sgammon 3y ago
  Why the downvotes? I honestly don’t understand.
deleted 3y ago
[deleted]
thewakalix 3y ago
This is formalizing existing practice, not introducing a new concept. [0] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#420 https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#420
- gary_0 3y ago
  Both of the uses in the article seem to be deprecated, though, and not used to imply "impairment". Kind of a dumb joke. What's next, "HTTP 69: Loop Detected Between Input And Output"?
  - lstodd 3y ago
    609 while we're at it. Why exclude third parties? And yes, that would be way more useful.
    - rablackburn 3y ago
      > And yes, that would be way more useful. ...that sounds like an example use case for the proposed status code. 420: Requester Impaired - Infinite loop It would allow you to signal to the requester that while their individual responses are fine, their session behavior is incoherent.
- rablackburn 3y ago
  Which explains why it's a playful name - the old Internet culture still shows up. And let's be honest, it's a great name when the lowest free options are 419 or 420. Some may roll their eyes at it, but it would certainly be a memorable status code.
fnordpiglet 3y ago
There are many occasions in my life where such a status would have saved me from extreme embarrassment. This would be especially useful in messaging and telephony services, or other mediums my ex’s use.
akersten 3y ago
This is a great example of a bad RFC: the description fails to motivate the necessity of establishing this concept of "rejected due to client impairment" let alone even define what "impairment" means in this context. Instead of where paragraphs explaining those would be, it instead talks right away about how "oh this applies to AI too, and by the way a proxy server is allowed to do this" - very small and irrelevant details in comparison!
- rablackburn 3y ago
  You appear to have skipped the introduction (which comes before the statement about this being useful for non-human operators like bots) where it says: >> This request code may be used to provide visibility in cases where one or more valid requests create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. Why this is considered necessary is explained in the next sentence: >> Network-controlled devices are being used for beneficial but potentially dangerous activities such as construction and remote surgery. Identifying requester impairment is important for both accurately assessing the risk a given requester presents and preventing damage caused by a high-risk requester.
  - akersten 3y ago
    I did read the intro, it similarly fails to define what does "danger" or "impaired" mean from the perspective of a webserver and why it would matter as part of the protocol. There's just nothing here that makes me think "this seems like something HTTP should be concerned about": > create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. "The risk a given requester represents" I mean... this is just so nebulous. Is this a special status code for webserver running in a breathalyzer? I'm convinced this is some kind of post-AI satire. To be clear I understand the need for specialized devices to prevent misuse and user error. But the HTTP protocol is like, the worst possible choice for where to build that out. This is a layer 0 concern, not layer 7. Who knows though. Maybe in a decade when Alcohol-as-a-Service startups are delivering fine liquor directly via the built-in straw of some next-gen Oculus headset, my virtual bartender will leverage this status when they cut me off.
tedunangst 3y ago
I'm thrilled to learn we've run out of real problems to solve.
1116574 3y ago
I found it mildly funny/amusing. Why would you want to announce to the client that he is tripping on a security? When erratic behaviour is detected, systems usually deny access or request more authentication. In the second case, this seems like a nice quality of life code, but this should be mentioned in the rfc and not left for me to figure out. Besides, a more generic "please reauthenticate now" would fit better (as to not expose the reason?) or even reusing the 403 forbidden could work for this usecase.

14 points by healsdata 3y ago

cratermoon 3y ago

"420 Requester Impaired" I thought this was an April 1 RFC.

openthc 3y ago
I'm here for the 420 jokes. This one wouldn't be good even on April 1st (or 20th)

tooker 3y ago

I read the entire thing and still can't tell if this is a joke.

Waterluvian 3y ago
My most charitable interpretation is that this is attention-seeking by the author. It’s not a good idea. It’s not funny.

sgammon 3y ago

I hope this is a joke, otherwise, I don't understand the pejorative use of "420" for this status code. Cannabis consumers would really love the dignity of being treated like any old alcoholic. /s

sgammon 3y ago
Why the downvotes? I honestly don’t understand.

deleted 3y ago

[deleted]

thewakalix 3y ago

This is formalizing existing practice, not introducing a new concept. [0] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#420 https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#420

gary_0 3y ago
Both of the uses in the article seem to be deprecated, though, and not used to imply "impairment". Kind of a dumb joke. What's next, "HTTP 69: Loop Detected Between Input And Output"?
- lstodd 3y ago
  609 while we're at it. Why exclude third parties? And yes, that would be way more useful.
  - rablackburn 3y ago
    > And yes, that would be way more useful. ...that sounds like an example use case for the proposed status code. 420: Requester Impaired - Infinite loop It would allow you to signal to the requester that while their individual responses are fine, their session behavior is incoherent.
rablackburn 3y ago
Which explains why it's a playful name - the old Internet culture still shows up. And let's be honest, it's a great name when the lowest free options are 419 or 420. Some may roll their eyes at it, but it would certainly be a memorable status code.

fnordpiglet 3y ago

There are many occasions in my life where such a status would have saved me from extreme embarrassment. This would be especially useful in messaging and telephony services, or other mediums my ex’s use.

akersten 3y ago

This is a great example of a bad RFC: the description fails to motivate the necessity of establishing this concept of "rejected due to client impairment" let alone even define what "impairment" means in this context. Instead of where paragraphs explaining those would be, it instead talks right away about how "oh this applies to AI too, and by the way a proxy server is allowed to do this" - very small and irrelevant details in comparison!

rablackburn 3y ago
You appear to have skipped the introduction (which comes before the statement about this being useful for non-human operators like bots) where it says: >> This request code may be used to provide visibility in cases where one or more valid requests create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. Why this is considered necessary is explained in the next sentence: >> Network-controlled devices are being used for beneficial but potentially dangerous activities such as construction and remote surgery. Identifying requester impairment is important for both accurately assessing the risk a given requester presents and preventing damage caused by a high-risk requester.
- akersten 3y ago
  I did read the intro, it similarly fails to define what does "danger" or "impaired" mean from the perspective of a webserver and why it would matter as part of the protocol. There's just nothing here that makes me think "this seems like something HTTP should be concerned about": > create a dangerous situation, there is a pattern of erratic requests with the potential for danger, or the requester is otherwise detected as impaired. "The risk a given requester represents" I mean... this is just so nebulous. Is this a special status code for webserver running in a breathalyzer? I'm convinced this is some kind of post-AI satire. To be clear I understand the need for specialized devices to prevent misuse and user error. But the HTTP protocol is like, the worst possible choice for where to build that out. This is a layer 0 concern, not layer 7. Who knows though. Maybe in a decade when Alcohol-as-a-Service startups are delivering fine liquor directly via the built-in straw of some next-gen Oculus headset, my virtual bartender will leverage this status when they cut me off.

tedunangst 3y ago

I'm thrilled to learn we've run out of real problems to solve.

1116574 3y ago

I found it mildly funny/amusing. Why would you want to announce to the client that he is tripping on a security? When erratic behaviour is detected, systems usually deny access or request more authentication. In the second case, this seems like a nice quality of life code, but this should be mentioned in the rfc and not left for me to figure out. Besides, a more generic "please reauthenticate now" would fit better (as to not expose the reason?) or even reusing the 403 forbidden could work for this usecase.