So, I saw here a couple of questions related to mine but I want to describe a more specific situation. Imagine your API always checks for the amount of daily requests made to an entry point. Once a specific client achieves this limit I'm returning 422 - "Unprocessable entity".
I guess I just want to consult whether someone has a different approach.
Whenever there are too many requests being fired to your server, you can always respond with HTTP 429: Too Many Requests. Check the RFC.
The 429 status code indicates that the user has sent too many requests
in a given amount of time ("rate limiting").
The response representations SHOULD include details explaining the
condition, and MAY include a Retry-After header indicating how long to
wait before making a new request.
For example:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
..body..
Related
If I am making an HTTP server, can I choose to ignore requests I don't want to respond to and let them time out?
I'm just wondering whether I am in any sense better off not responding to requests from potentially malicious sources than responding to them with data I'd rather not serve up, or responding with some 403 Forbidden or similar response that lets them know I exist.
A 403 should suffice. But I wouldn't let it just time out. If someone is trying to be cheeky, a time out will be more informative than a Service Unavailable 503.
I answered a relevant question a while back, read the question/answer, it's about a specific use case, but it does mention cases where you don't want to return an HTTP status code because it gives too much info.
RFC - 404 or 400 for relation of entity not found in PUT request
Also have a look at this list of HTTP Status codes, you can always use something like Too Many Requests 429, a Not Acceptable 406 or even something like I'm a teapot 418 ;)
How does an HTTP client definitively determine whether a login was successful when using Basic Authentication? I've always thought that it was simple - look at the response code:
200 = Successful
401 = Unsuccessful
This is not correct. If you read RFC 2617 it says:
If the origin server does not wish to accept the credentials sent with
a request, it SHOULD return a 401 (Unauthorized) response. The
response MUST include a WWW-Authenticate header field containing at
least one (possibly new) challenge applicable to the requested
resource.
The word SHOULD is tricky, and in fact I've seen devices that do not return a 401 on login failure. This would suggest:
WWW-Authenticate does not exist = Successful
WWW-Authenticate exists = Unsuccessful
This is also incorrect. I'm playing with a TP-LINK router that provides the following headers:
- Server : Router Webserver
- Connection : close
- Content-Type : text/html
- WWW-Authenticate : Basic realm="TP-LINK Wireless N Router WR841N"
The response code is 200.
Here we have a 200 with a WWW-Authenticate!!!!!
Given all of this, what is the DEFINITIVE way to determine whether a BA login was successful?
RFC 7235 obsoletes RFC 2617 and one of the corrections it brings is to point out that, SHOULD is to be interpreted as per RFC 2119. (This was perhaps omitted because it is pointed out in RFC 2616, which goes hand-in-hand with 2617):
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
So, it's not just a matter of "well, you should do that, but we understand if you don't" as should means colloquially, but rather "you must do this, unless you have an extremely good reason that you can clearly state".
If a server has a very good reason for not sending a 401, it's most likely because it is sending some other error code (e.g. 404 to pretend the resource doesn't exist unless you've successfully authenticated). The wisdom of sending anything other than 401 is perhaps questionable, but the only reason to send 200 is because you want to indicate that the response is successful. Really, while the should does allow something other than 401, it really doesn't allow 200.
Including WWW-Authenticate on the other hand, definitely doesn't mean the authentication wasn't successful. It's allowed at any time, and with other schemes apart from Basic can be necessary on successful requests (to allow a nonce-count to increment, for example).
In short you've got three possible states: Success, Authentication Error, Some Other Error. The should allows for the last of those. If you get a 200 then you were successful (or well, the server is behaving wrong, but that always applies anyway).
The 200 status is what counts. That the server keeps including WWW-Authenticate simply is a bug.
And yes, I tested this, I happen to have the same router over here.
I was reading the specification about HTTP/1.1 redirection codes. I have many questions:
There's a text like this:
If the 301/302/307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Q: In what sense is this applied by browsers? I never saw any 301/302 response making my browser ask me if I wanted to confirm the operation (example: receiving a form by PHP and then redirecting to a new output).
It's clear to me that most of the times we Process-and-Redirect using a 302, instead of 303 (See other - which was created for exactly THAT purpose). However, I'm confused about 301 302 (please note: the intended, original behavior) and 307. Q: What are the differences between them in a practical example / use case?
Most 301/302 redirect responses occur on regular GET requests (as opposed to POST requests) so there is no confirmation needed. Also, even though confirmation for non GET/HEAD requests is technically recommended by the RFC, the RFC also mentions that:
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
302 tells the user agent to continue using the old uri in future requests. 303 tells the user agent to use the new uri in future requests.
In addition, as the note in the RFC you link to mentions:
Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.
I'd argue that the RFC should be changed so that If the 301/302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Should be rewritten as If the 301/302 status code is received in response to a request other than GET or HEAD, the user agent SHOULD NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Since otherwise most current user agent are violating the RFC.
I have a request (POST) which creates a resource. This resource takes a long time to create (up to hours), but its id is created immediately.
It seems to me the most appropriate flow is:
POST /thing - response is 201 Created with "URI for the resource given by a Location header field" (as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)
Start polling GET /thing/id to which the response should be:
As long as resource has not been prepared - 204 No Content
Once the resource is ready - 200 OK with the resource returned in the response body
I am seeking opinions/ advice because I am basing my opinion on (a lot) of reading and less so on experience and this seems different from most recommendations to initially return a 202 Accepted and to use 204 only in response to http DELETE
You can choose to return 202 Accepted upon POST:
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
Now as explained here, you can alter your response body or headers to include something like a Status value indicating whether the resource generation has completed when the user performs a GET request. Any positive status code will do.
Alternatively, as advocated here, you can also return 202 for the GET while the entity is being created.
All other applicable status codes can be considered 'definitive', because when a client receives 204 No Content, it cannot differentiate between "entity not yet generated" and "entity was generated, it is empty".
Client sends a POST or PUT request that includes the header:
Expect: 100-continue
The server responds with the status code:
100 Continue
What does the client send now? Does it send an entire request (the previously send request line and headers along with the previously NOT sent content)? Or does it only send the content?
I think it's the later, but I'm struggling to find concrete examples online. Thanks.
This should be all the information you need regarding the usage of a 100 Continue response.
In my experienced this is really used when you have a large request body. It could be considered to be roughly complementary to the HEAD method in relation to GET requests - fetch just the header information and not the body (usually) to reduce network load. 100 responses are used to determine whether the server will accept the request based purely on the headers - so that, for example, if you try and send a large POST/PUT request to a non-existent server resource it will result in a 404 before the entire request body has been sent.
So the short answer to your question is - yes, it's the latter. Although, you should always read the RFC for a complete picture. RFC2616 contains 99% of the information you would ever need to know about HTTP - there are some more recent RFCs that settle some ambiguities and offer a few small extensions to the protocol but off the top of my head I can't remember what they are.