I am currently working on the payment gate way which connects to Third Party Payment API by giving some information including return_url (that they will send the payment result back) and notify_url (that send the same information as in return_url in case there are some issues with the cardholders' internet connection or issues with their browser).
After processing at their end, my end processed return page and notification page successfully.
But they said as follows.
Merchant would have to response with HTTP 200 OK to indicate that the notification is received successfully.
They would retry (up to 5 times) to resend the notification again if HTTP 200 OK response is not received after specific timeout (currently is fixed to 60 seconds timeout).
So I put the following codes in the notification page.
If Response.StatusCode <> HttpStatusCode.OK Then
Response.StatusCode = HttpStatusCode.OK
End If
I think this snippets aren't enough because they are still calling to my notification page 4 times.
I check the log tables. Although the process is complete, the log are still coming in after some interval.
Anybody can help about to response with HTTP Status 200 .
Any suggestion are appreciated.
Related
I have long operation, which called via Web API. Status code 102 says to us:
An interim response used to inform the client that the server has
accepted the complete request, but has not yet completed it.
This status code SHOULD only be sent when the server has a reasonable
expectation that the request will take significant time to complete.
As guidance, if a method is taking longer than 20 seconds (a
reasonable, but arbitrary value) to process the server SHOULD return a
102 (Processing) response. The server MUST send a final response after
the request has been completed.
So, I want to return 102 status code to client, then client waits response about result of operation. How to implement it on .NET?
I read this thread: How To Return Http 102 Processing in Asp.Net Web Api?
This thread has good explanation what is necessary, but no response. I don't understand how it implement on .NET, not theory...
Using HTTP 102 requires that the server send two responses for one request. ASP.NET (Core or not) does not support sending a response to the client without completely ending the request. Any attempt to send two responses will end up in throwing an exception and just not working. (I tried a couple different ways)
There's a good discussion here about how it's not actually in the HTTP spec, so implementing it isn't really required.
There are a couple alternatives I can think of:
Use web sockets (a persistent connection that allows data to be sent back and forth), like with SignalR, for example.
If your request takes a long time because it's getting data from elsewhere, you can try pulling in that data via a stream and send it to the client via a stream. That will send the data as it's coming in, rather than loading it all into memory first before sending it. Here's an example of streaming data from a database to the response: https://stackoverflow.com/a/45682190/1202807
Here is my LogicApp:
It is calling API which launches process running for 10 minutes, returns 202 and returns location header for status checks and when is done it returns 200. I have asynchronous pattern enabled and time limit set to PT2H in this Logic app. So I expect it to run for about 10 minutes periodically checking status until 200 is received or time out.
However, in overview tab this app shows successful run with duration of 1.09 seconds.
This is a bit counterintuitive. What am I missing?
To check the setup, I updated my API to return status 400 upon completion and my LogicApp is supposed to send email in case of error or time out. API ran fine and returned 400 status, but I did not get an e-mail, so I do nothing polling is happening correct. Any thoughts?
I do repro in my lab after creating a ISE for logic app by using as follows with duration of 5 mins. And after 5 min. received mail as well.
Going to Logic App designer and created with Recurrence Core.
Added scheduler> Delay for the time to hold for http core in delay section as follows:
Then added HTTP core> settings> Asynchronus pattern ON and Timeout set as below:
And set same setting for the send email as well from the setting.
]5
And after that we can save it and run the Logic app . Then We can check the overview as per delay time which i set earlier:
For further information please refer the How Long will aLogic App Continue to check a HTTP 202 Accepted Response and the Doc.
I am getting below error when response is larger in size, We can fix below by enabling Streaming in Apigee ( Currently out of scope as needs work at all up streams)
The error pasted below: {"Envelope":{"Body":{"Fault":{"faultcode":"soap:Server","detail":{"source":{"errorcode":"protocol.http.TooBigBody"}},"faultstring":"Body buffer overflow","faultactor":{}}},"encodingStyle":"http:\/\/schemas.xmlsoap.org\/soap\/encoding\/"}
I am planning raise fault when we get above error from downstream system. What should be HTTP Status Code ?
413 Request Entity Too Large
400 "Message: Response is large"
My vote is for 500 - Internal Server Error, with some detail in the body. A 4xx error code indicates to the client that they should retry the request after making some modifications. That does not seem to be the case here.
Well, it looks like it should be a 500 error. And, as a good practice, you should add some details in the body or a good and clear message, as said before by some wise people here.
All the 4xx errors indicates that the system is fine but your request is not. Some examples:
400: will not process the request due to a client error. In the past this code was only for syntax error, but nowadays is more generic: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1
403: indicates that the server understood the request but refuses to authorize it.
415: the payload format is not supported
422: the request format and syntax are ok, but the server will not process it. Normally a good one to raise when validation fails or some semantics are not correct. More: https://www.rfc-editor.org/rfc/rfc4918#section-11.2
You can check all RFCs you want and will not find a 4xx error for this situation. Unless you misexplained and the user should change the request in any way in order to get the right result. In this case, 422 could be your choice, for example, if the request is in the right format and syntax, but the user is requesting too many resources.
If you will/can not do anything to return a response with expected body attributes to the clients in this case, then you should return 500 with a good message.
I saw services return 200 and the details of the issue at some part of the response with a good (okay) message as errorMessage or something in similar cases.
The idea here is to propagate the exception so that the client app can give a proper message to the end users, so let the client application know about the issue with the message.
HTTP 413 Payload Too Large is wrong status code for this situation because it tells to the clients that you are sending large request and it leads to confusion of them.
HTTP 400 Bad Request is wrong status code for this situation because the request is correct and server knows what it wants to get but because of its own limits, server doesn't want to answer to this amount of response size.
HTTP 403 Forbidden should be your choice.
The server understood the request, but is refusing to fulfill it.
Note, mostly it is a good idea to tell the reason of refusing the request with correct response status code and custom message.
If I understood your question correctly, Your API server is not able to full fill the request it got because the response for the request is too large.
In this case, We should be returning 503 - Service Unavailable. This way we can indicate that our API server not able to respond to the request temporarily, It's not a complete downtime of the API server and it's not happening for all the requests at a time which we got. This is gonna happen only when the response/payload is too large and that too for the selective requests. Since our API server is not able to handle and respond to the request at that moment it should be.
I am scripting for an application in which there is a search to be done and when search is hit after entering required parameters the request is sent to the server after 20 sec the request is passes with 200 response code and automatically send same request again every 20sec until actual response is received. Does anyone came across this kind of application. Please let me know.
Thanks
I am building an Air application that long-polls a Spray server to get relevant updates.
I am new to Spray and have read that, if requests are not handled on time, a 500 timeout error is automatically sent to the client by the framework. I can catch this error on the Air side, and then send another request, etc.
Are there any drawbacks to using this approach (I cannot think of any) or is it better to avoid the timeout and send back some sort of "no news" message to the client instead?
I would say, from a RESTful perspective, that the response should pertain to the state of the resource. Looking at the available response codes:
204 No Content The server successfully processed the request, but is
not returning any content.
This states that the request was carried out successfully yet there is nothing to return.
204 No Content