Live data from Hacker News

999 Request Denied

http.dev

11–20 of 74 posts

Re: 999 Request Denied

#11
This is just wrong and bad.

The uses described should very clearly be 403 Forbidden where it’s refusing to respond based on user-agent, and 429 Too Many Requests where it’s rate limiting.

The spec says https://www.rfc-editor.org/rfc/rfc9110#section-15-6>:

> Values outside the range 100..599 are invalid. Implementations often use three-digit integer values outside of that range (i.e., 600..999) for internal communication of non-HTTP status (e.g., library errors). A client that receives a response with an invalid status code SHOULD process the response as if it had a 5xx (Server Error) status code.

So, the spec declares it invalid, and its suggested handling yields the wrong semantics (server rather than client error).

Given the notes they have on things like 430, I’m astonished at them not noting the problems with this code.

Re: 999 Request Denied

#13
post #8

> When sending an HTTP GET or HEAD request to LinkedIn for a specific profile [...] > It will also be returned if there are too many HTTP requests in a single day. This is similar to the HTTP 429 Too Many Requests error message. Similar? That is excatly what 429 was made for, or not? This is weird or just lazy.

I believe this is a meme making fun at LinkedIn for using the wrong status code…

Re: 999 Request Denied

#15

I’m going to bet that every 999 could be defined more accurately using an existing code. For me, if the server cannot specifically tell you what kind of error happened, it’s by definition a 500. My API is internal, but it’s been nice to consider, “all 500-level errors are my team’s problem to fix or represent more accurately as a 400-level.”

Yep.

4xx: "You asked for something in a way that I can't respond" (auth error, unknown path, etc.)

5xx: "You asked for something in a valid way, but I can't respond right now" (outage, bug, etc.)

Re: 999 Request Denied

#16
post #7

I've never realized that http status 999 was a thing. I've often used 401 to tell user something similar to "denied"...which i get is different in that "unauthorized" (for 401) is the browser telling the user, while i suppose 999 would be the server telling the client to tell the user a generic "denied"...so there's a difference there, but a little nuanced i suppose. I guess TIL.

It's not a thing and this post should be taken down before some bright kid figures it's a good idea to copy.

Re: 999 Request Denied

#17
This is super unprofessional. 999 means nothing, therefore it cannot be acted upon, therefore it is totally useless. Best description which I can come up with is "I don't like you and I won't say why, because I don't like you".

The expected client behavior is sending in return an empty http post request with wtf header and value "I feel this server is passive aggressive towards me."

Re: 999 Request Denied

#18

I’m going to bet that every 999 could be defined more accurately using an existing code. For me, if the server cannot specifically tell you what kind of error happened, it’s by definition a 500. My API is internal, but it’s been nice to consider, “all 500-level errors are my team’s problem to fix or represent more accurately as a 400-level.”

I think the semantics of 999 is "bugger off, you are not supposed to be here. I will not grace you with a proper status code". Because sending a status code, even a 4xx or a 5xx, acknowledges the request and plays along by giving a well-formed answer.

If you want to respond impolitely, you could just terminate the connection, or send plaintext "Don't scrape me, we are watching you" instead of a HTTP response, but I can imagine that doesn't work properly with proxies and middleware.

The conventional nonsense response "418 I am a teapot" has been standardized unfortunately. But `return Response("Request Denied", status=999)` is easy to write and does the job.

Re: 999 Request Denied

#19
The page explaining all the codes should make it clear that using status code 999 is a bad idea.

One reason why it's bad is because it violates RFC 2616 (§6.1.1):

    The first digit of the Status-Code defines the class of response. 
    The last two digits do not have any categorization role. 
    There are 5 values for the first digit:

      - 1xx: Informational - Request received, continuing process

      - 2xx: Success - The action was successfully received,
        understood, and accepted

      - 3xx: Redirection - Further action must be taken in order to
        complete the request

      - 4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled

      - 5xx: Server Error - The server failed to fulfill an apparently
        valid request

Re: 999 Request Denied

#20

I’m going to bet that every 999 could be defined more accurately using an existing code. For me, if the server cannot specifically tell you what kind of error happened, it’s by definition a 500. My API is internal, but it’s been nice to consider, “all 500-level errors are my team’s problem to fix or represent more accurately as a 400-level.”

I think the semantics of 999 is "bugger off, you are not supposed to be here. I will not grace you with a proper status code". Because sending a status code, even a 4xx or a 5xx, acknowledges the request and plays along by giving a well-formed answer. If you want to respond impolitely, you could just terminate the connection, or send plaintext "Don't scrape me, we are watching you" instead of a HTTP response, but I c…

> you are not supposed to be here

Isn’t that a 403?

I’m not sure what value there is in saying “beep boop” rather than “you can’t come in.” If you really intend what you’re saying, why not just drop the tcp connection without any http response as you suggest?

Post reply on HN