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
Related
At work I often see people talking about the webhook and postback patterns interchangeably, I'd like to know if there is a difference.
I've also noticed two patterns:
There's one in which you send an HTTP request to an endpoint stating through a header field an address to which the result of the asynchronous operation should be sent;
Another one in which you previously set an address to which the results should be sent. And then, on your HTTP requests, you will not inform this address again, but the results will be sent to the address previously configured.
Could anyone explain the difference, if there is any?
Thanks in advance.
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.
Is there a protocol (or framework) that ensures that when a request fails, it fails on both the client side (iOS, Android, etc) and server side, and when it succeeds, successes on both sides?
The request might be completed on the server but because of dropped network connection, the client does not receive the response and thinks that the request failed.
The Post-Redirect-Get pattern can be adapted to this. The post part is used to submit the request, and the redirected get will be to a "results" page where the client can acquire the status (in progress, failure, success. etc).
Obviously, a client should not conclude from a network problem that the request failed. It should simply be prepared to wait and/or retry to obtain the status.
The interesting case is where the initial request submission is incomplete, i.e. nothing, not even the redirect comes back. This is where the adaptation comes in. The initial data submission should be after the server has generated a transaction identifier that the client can use as an alternative for status requests. (E.g., a form with a static field "Please save and use this tracking ID for status inquiries".)
If your question was whether this fallback can be automated at the protocol level, the answer unfortunately is no.
I'am writing an API to make users can subscribe to things. An user can subscribe to anything via submitting a POST something like this:
{
"item_id": "c13",
"requested_status": "subscriber",
"sure": true,
}
Here you can see a sure parameter. I'am using this to avoid making subscriptions accidentaly. If client sends that info without sure parameter API rejects that request to make GUI ask "are sure to subscribe this?". If user confirms, same post happens again with sure parameter. And subscription (or unsubscription) happens.
So, when I am rejecting that request because there is no sure parameter. Which response code should I use? I thought 400 (bad request) can be used but not sure.
Thanks for you response.
HTTP codes are codes with a pure technical meaning. What you want is not a technical problem and shouldn't be handled with technical means.
Since the reponse was received and contained technically correct values (not the same as functional valid values!), you should send a 200 - OK status. The content of your response should be the action to perform next. In this case, ask the user if he/she is sure.
If you work with Post-Redirect-Get, a 303 - See Other status is your best option.
So, I want to use node.js and http request pipelining, but I want to use HTTP only as a transport, nothing else. I am interested in exploiting the request pipelining feature. However, one problem that I am running into is that till a send a response to a previous request, the next requests's callback isn't fired by node. I want a way to be able to do this. I shall be handling the ordering of results in the application. Is there a way to do this?
The HTTP RFC mentions that the responses should be in order, but I don't see any reason for node.js to not call the next callback till the 1st one is responded to. The application can in theory send the response to the 2nd query as a response to the 1st one (as long as there is some way for the recipient to know that it is a response to the 2nd one).
The HTTP client in NodeJS does not support pipelining. (Slightly old post from Ryan, but I'm fairly sure it still holds.)