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
Related
I am returning a stored custom HTML file for a particular request using ngx.exec function. I want to set the right HTTP response code. I am not able to figure out how to do that. Even if I set ngx.status before ngx.exec the response code returned is always 200 to the client.
Is there a way to set the response code?
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.
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.
I send some values using spring httpClient to other url. And about that question as I know if I send name=mister age=30 values, received page get that values not http status values, right?
Http status values are for sending page's not receive page's.
I mean, if I send those values, receiving page gets http values.
If receiving page want to get that values, I have send that values, is that right?
My team manager said to me that http has request and response so, if you send some values to other url, other url gets http status values.
But as I thought that is little bit anyway I can't understand my team manager's saying, please let me know, receiving page gets http status when I send some values.
Your team manager's statement is correct. ("the http status have to be written.", "http has request and response. so there should have that http status value result"). What he/she mentioned is HTTP response status code, which should be returned (with correct code) whatever the response is.
No matter your result (name=mister and age =30 etc.) is a static page or an Ajax response, the response code should be 200 OK when the result is generated successfully (correct business logic, no error happens). But when something bad happens, it is important to let client know why server failed to return result -- maybe it is because the request format is incorrect (400 Bad Request), there is a typo in request url (404 Not Found) or some error in server code (500 Internal Server Error). Send name=null and age=null to client with 200 OK is incorrect and bug prone. Without definition of these error status code in document, backend engineer have to communicate with frontend engineer during the development, API by API, case by case, which is very time consuming and inefficient.
I think your TODO is: for the API that accepts name=mister and age =30, define success case and different failure case, then assign correct response code to them.
I realize this might sound like an odd question, but I'm seeing some odd results in my network calls so I'm trying to figure out if perhaps I'm misunderstanding something.
I see situations where in isolated incidents, when I'm uploading data, even though the response is 200, the data doesn't appear on the server. My guess is that the 200 response arrives during the initial HTTP handshake and then something goes wrong after the fact. Is that a correct interpretation of the order of events? Or is the 200 delivered once the server has collected whatever data the sending Header tells it is in the request? (cause if so then I'm back to the drawing board as to how I'm seeing what I'm seeing).
It means it has been successfully finished. From the HTTP /1.1 Spec
10.2.1 200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end server.
Finished. It doesn't make sense otherwise. Something might go wrong and the code could throw an error. How could the server send that error code when it already sent 200 OK.
What you experience might be lag, caching, detached thread running after the server sent the 200 etc.
A success reply, like 200, is not sent until after server has received and processed the full request. Error replies, on the other hand, may be sent before the request is fully received. If that happens, stop sending your request.