Is there a way to implement a "delivery receipt", or, "quick response", from the server before the start of a long running process (that will delay the actual response content)?
I mean this:
request -> server receives -> res.send(200) ((but keep this 'res' alive!)) -> server long running process -> res.send("actual response")
This would be very useful in the app side, so I get to know that timeouts are really happening because of the process and not because the server is offline. Also, I wanted to avoid making two requests, one following the other one.
HTTP Status Code 100 CONTINUE can be used for this purpose. See https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1
According to the RFC, 100 Continue is an interim response which must be followed by a final response once the request has been completed.
Related
I have built a testsuite for a service orchestration with Citrus framework.
In one case, when the former request results in an "empty" response, the last orchestration step, a HTTP request, is skipped.
How can I test that this last request is NOT executed? I did not found a way to do this.
When I do not check this with an explicit expectation, the test is successful no matter if a request is executed or not.
I have an HTTP server simulation in place to respond according to the request. What I was looking for is something like
runner.http(action -> action.server(simulation)
.receiveNothingDuring(5000)
);
to wait for 5 seconds for a request to arrive and SUCCEED if nothing arrives. This is kind of the inverse of the normal receive assertion.
You can use the receiveTimeout action that is exactly what you need:
runner.receiveTimeout(action -> action.endpoint(simulation)
.timeout(5000));
See also descriptions in docs
I'm using Postman to debug my WebAPI.
There are 2 cases where Postman does not get any answer from my API:
1. When I set a breakpoint for incoming requests
2. When my API is not running
In 1st case, Postman waits (for inifinity theoretically), but in the other it returns me an information that something is wrong after a few seconds.
So my question is: How does that work? In the 1st case, request gets to my server, but it doesn't send any response until I stop debugging, which can take minutes possibly. In the 2nd case, Postman also does not egt any repsonse, but somehow it knows after a few seconds that it will never get it.
In first request the connect to server is successful and it waits for a reply until postman timeout defined.
Second request it connect to server and get reply immediately with an error.
You can increase or decrease max time postman wait for response by using XHR Timeout
Set how long the app should wait for a response before saying that the server isn't responding.
I use a payment gateway which uses the relay response url of my web application to return the transaction response or receipt information. The problem is that it uses a timeout i.e if it is 10 seconds since it made the request to the relay response url and if the relay response url didn't respond within that time then it will timeout. The problem i am trying to avoid or minimize is for the url to respond within the timeout period. One thing i have noticed is that this method that relay response url points to over the time has gotten bulkier and this may amount to the occasional timeouts that is happening. One solution i think could be to render partial response quickly like "Please wait...". If the payment gateway receives something from the relay response url then it shouldn't timeout. After that when the heavy processing is complete then the relay method sending full response which will be receipt in most cases. Is there a way to achieve this? I appreciate any help! The framework i am using for my application is grails 2.0.
I thought something like this would work but i was wrong.
def receiptFinal(){
...
}
def receipt(){
render "Please wait..."
redirect(controller: 'payment', action: 'receiptFinal')
}
Yes,it is quite possible I guess. Your payment gateway has to make two requests. One is to confirm whether validation/payment is all right or not. And, Second request to the client would be final response (like receipt etc)
It would totally depend on payment gateway.
--
Jitendra
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.
I've poked around a bit, but I don't see an HTTP status code for when a request's succeeds, but there is an error after the "point of no return".
e.g., Say you process a request, its committed to the database, but while returning the result you run of memory, or encounter a NPE, or what have you. It would have been a 200 response, but now, internally, you aren't able to return the proper, well-formed response.
202 Accepted doesn't seem to fit since we've already processed the request.
What status code means "Success, but errors"? Does one even exist?
HTTP doesn't have such a status code, but there is a best practice that allows you to handle such situations - redirect the user after a POST operation.
Here is a break down -
A POST request tries to modify data on the server
If the server fails, it sends a 500 error to indicate failure
If the server succeeds, it sends a 302 redirect response
The browser then sends a fresh GET request to the server
If this fails, you get a 500 error, otherwise you get a 200
So, your use case of 'Saved data but can't retrieve it immediately' translates to a 302 redirect for the initial POST, followed by a 500 for the subsequent GET.
This approach has other advantages - you get rid of the annoying 'Are you sure you want to resubmit the data?' message. Also keeps your back/forward/refresh buttons usable.
If the server is aware that it has encountered a problem, it should normally return a 5xx error. The most generic one is the 500 Server Error, which the RFC 2616 defines as follows:
500 Internal Server Error
The server encountered an unexpected condition which prevented it
from fulfilling the request.
Then it's the client's responsibility to reattempt the request. If the previous request was partially committed, it's the server's (or the database's) responsibility to roll that back, or to handle the duplicate transaction appropriately.
I agree with #Daniel that the proper response is an HTTP 500 (server error). The web application has to be written to roll back the transaction when there is an error, not leave things half-finished.
One thing you can leverage in your web application is "idempotency". This is the property of a function (or operation) that you can repeat it as many times as you like with the same result. For instance if a read fails, the client can simply retry it until it succeeds. If a deletion appears to fail, the client can again retry and the server will treat the request as valid whether or not the resource being deleted is already gone. And if an update appears to fail, the client can retry that until it gets a successful return from the server. The REST approach to architecting web services makes heavy use of idempotency to make operations robust in the face of error.