We have exposed a HTTP endpoint with POST method. To make a successful call the clients has to make the POST call with a request body and other required parameters.
When we hit the endpoint directly in the browser the response says 200 OK. Its a GET call. there is no implementation for GET.
The question is - an endpoint which supports only POST should throw an error while hitting directly on the browser with a GET ?
What should be the best error. Do we have to handle this in GET saying GET is not appropriate method on this end point?
Or is it correct to leave the GET response as 200 OK - to make the clients feel the end point is up and running?
If you're asking about what an HTTP server SHOULD do... the answer is: it has to implement GET and HEAD. See RFC 7231.
Related
I'm getting HTTP Status 405 – Method Not Allowed: "The method received in the request-line is known by the origin server but not supported by the target resource."
when I'm making the following REST API call
https://myantserver.example:5443/WebRTCAppEE/rest/v2/broadcasts/{id of my stream}/recording/true
Not sure what I'm doing wrong... Is there any setting I need to configure? The streams get saved just fine if i enable "Record Live Streams as MP4"
But I want to only record specific streams. If there was any way to "Record all livestreams where the stream ID includes a specific string" that would work as well.
Any suggestions appreciated, Thanks!
Solved it, the problem was that I was making a POST request instead of a PUT request
I’m wondering if there is a general convention for this: When implementing a HTTP health check for any given application where you are not interested in any response body but just the status code, what would the default/expected endpoint look like?
Using a HEAD request - and returning 200 or 204 status code (which one of those?)
Using a GET with 204
something else?
As of my experience, people use mostly GET and 200. A health check wouldn't respond too much content, so no use of making a HEAD request. But this is mostly the case with a dedicated health check URL.
Today's cloud systems often use Kubernetes or OpenShift. They appear to use a GET request. I think they'll probably want to get a 200ish response code, so 200-299:
https://docs.openshift.com/enterprise/3.0/dev_guide/application_health.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Another example, Drupal defines the HTTP response code to be 200:
https://www.drupal.org/project/health_check_url
In Oracle's Infrastructure-as-a-Service docs you can choose between GET and HEAD requests, but the default is HEAD:
https://docs.oracle.com/en-us/iaas/api/#/en/healthchecks/20180501/HttpMonitor/
Use a GET with 204 possibly supporting also HEAD with same status code
A HEAD should give the same response as GET but without response body, so you should first know/define what the GET response gives out in terms of headers (and status code), then, if you want, you can support also HEAD on the same endpoint, returning the same status, in this case 204.
Note that if GET employee/34 anwswers with 404 also HEAD must anwser with same code. That means one must do the same work as for GET: check if employee esists, set status etc. but must not write any response. Tomcat supports this automatically as it uses for HEAD request a response object that never writes to the "real" response, so one can use same code handling GET
For a check one may consider also TRACE but it produces a response body / output mirroring what you send to it, is different, I haven't seen implemented anywhere.
TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic
information.
I use lua script to generate data from the parameters and bodies, and then send the data to the other server.
When i handle a GET request, nginx returns a normal response.
However, a 404 not found error occurs when handling POST requests.
However, internal operations were normal and sent the data to the other server.
Only the request method has changed.
If i explicitly pass the value to ngx.say or ngx.exit, i get 200 response normally.
Why? Is it necessary to explicitly return a response code when using a post request with a lua script?
In addition, I am using empty_gif.
I have searched for the above problem.
empty_gif can only be used to respond to GET and HEAD request methods
so I will use 204 response code
What is the difference when we use 200 response status code for a forbidden page with an error message saying 'Access Denied' instead of using 403 response status code?
Are there any security implications?
The HTTP Response codes convey information about how the server has processed your request. So, if the server responds with 200, it means: "OK, I have received your request and processed it successfully". If it returns 403, it would mean: "I received your request successfully, but you don't have access to this resource".
However, technically they are both returned in the same format, in the same way in the response HTTP header like this:
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
The difference is in the meaning. And the meanings are defined in the standard.
So, when you are responding with code 200, you are telling the client that it is all good and dandy. If you are responding to client with 403, you are saying that the client doesn't have permission to this resource. Remember, there can be different clients: web browsers, crawlers, ajax requests from javascript, etc.
So, if you are sending a login form with 200 code:
Users who are using a web browser would understand that they need to login.
Google crawler will index your members/quality-content URL with the login form and will not understand that actually, the original content is different and it should not index this page with the login form.
Javascript with ajax callback will run success callback, when it should be running error callback function.
So, basically, make us all a favour and follow the standards! :)
Answering your second question, no it does not make your application any less secure.
The reason for this decision might be that error message was not visiable using Internet explorer like described here: How do I suppress "friendly error messages" in Internet Explorer?
Actually the correct way is to use the right HTTP error code and make the error message longer than 512 bytes as described here:
https://support.microsoft.com/en-us/kb/294807
Response status codes are intended to help the client to understand the result of the request. Whenever possible, you should use the proper status codes.
The semantics of the status codes are defined in the RFC 7231, the current reference for HTTP/1.1.
While the 200 status code indicates that the request has succeeded, the 403 status code indicates that the server understood the request but refuses to authorize it:
6.3.1. 200 OK
The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. [...]
6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any). [...]
Returning 200 will work, for sure. But why would you return 200 if you can return a much more meaningful status code? If is there any good reason, this should be added to your question.
I'm doing an AJAX call to set the username. If the username is already taken what HTTP code should I return?
You can use 409 Conflict.
Indicates that the request could not be processed because of conflict in the current state.
I would choose 422 Unprocessable Entity . Lot's of rails developers use this for all validation errors.
And yes, it is totally appropriate to evaluate the error status and render the error message with javascript. This is especially useful, if you are using the same actions for an API. Then your ajax requests are accessing the same API that you would expose to other developers.
There is no rule here, it is up to you. However, as #rationalboss said, it makes sense to return 200 with a message since the HTTP request has succeeded, the error is unrelated to the request.
400 errors mean the request itself was not correct in some way, like wrong verb or missing parameters.
The question here is about interpretation, both from software clients and from humans and it might be better to stay away from error codes when there is no HTTP error.
There is no HTTP Code for name already taken. Please see List of HTTP Status Codes.
If you are using AJAX calls to set the username, why not just show the error in HTML? This is more user-friendly as your visitors would know what the actual error means, instead of seeing some 4XX code.