I want to display appropriate error message when a connection is lost with a server. During a GET request the browsers "Connection Lost" message is displayed but when a POST request is made and no response is displayed the page doesn't respond properly. I am developing the page in ASP.net
Hope to hear fast responses.
Thanks in advance.
HTTP is not designed to be connected, it is stateless. before ASP.NET SingnalR was born, everything is just request-response. No matter GET or POST, the server should always send response to the client.
A "failed" post, should also be responded but with a status code like 500. In your case, you want to detect if a network connection is cut off, so the "failed" will mean "timeout" for you.
From server side, you cannot control it. So you can only do it on client side. such as using JavaScript to send a POST request, and if the server did not response in 15s, you can call it "connection lost", and display a message on your webpage.
Facebook chatting window is using this way. It will have a javascript function running on client browser, and keep "ping" the server to tell if the connection is OK.
Related
What is the correct format for sending an HTTP 403 forbidden message?
I'm writing a proxy in c for a homework project that has a content filtering system built in. When my proxy detects that a server's response has certain keywords that are contained in the content blacklist, I would like to send a HTTP 403 Forbidden message.
Currently, I am sending the message as: "HTTP/1.1 403 Forbidden\r\n\r\n" (without the quotes) as per this standard: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.3
When I send this message, the browser doesn't display an error and looks like it's still trying to load the page.
Are there any required header fields for this http message that I missed? Also, is this the correct usage for the 403 error? I couldn't find anything else that would be more fitting, so I chose 403 because the client won't automatically re-request the data.
Thanks in advance for any help!
For those struggling with this issue as I did, you need to make sure to close the socket or set Connection: Close as Sami noted in the comments. I assumed that you could keep it open so they could send another request with http persistent connections, but they will need to open a new connection.
As for the html displayed, you can send a body with the response (make sure you set Content-Length) that contains the html you want displayed.
Finally, here are two references, one to the HTTP response spec, and the other to the Amazon Restful response spec:
https://www.rfc-editor.org/rfc/rfc7231#section-6.5.3
https://developer.amazon.com/docs/amazon-drive/ad-restful-api-response-codes.html
If application will return response HTTP 204 .
What a correct header connection value (close or keep-alive)?
204 means there is no body to send back. You would still typically keep the connection open for subsequent requests so don’t have to close it this point.
Think of this scenario:
A web page has a “contact us” form which makes an XHR call rather than a POST. In that case you might send back a 204 to say the XHR call was successfully logged but you can keep the connection open so user can still browse the rest of the site without having to reestablish the connection.
If however your endpoint is for API calls only and no further requests will me made sending connection: close may make sense to save server resources.
The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional
content to send in the response payload body.
So according to my understanding, as the server doesn't have anything else to send in the response, the header should be 'close'
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 am using Windows Authentication to secure ASP.NET MVC5 application.
Everything works ok, I'm prompted to enter credentials via browser popup, and content it served properly.
However I do notice constantly that some requests are being sent 2 times, or more, with receiving 401 (Unauthorized) code, but shortly after requests are issued again and 200 (OK) is returned.
I assume that is part of negotiation with WWW-Authenticate and Authorize requests headers, but what is unclear to me is why this has to happen all the time even though credentials were supplied at the very start?
Is this normal behavior?
If not, how can it be fixed?
If yes, is it a big performance hit?
Attached is the combined screenshot of Fiddler and Firefox developer console.
What you are experiencing is the normal behavior. Here is a (very) short description of how the authentication works:
Request is sent to server (without credentials) => not authenticated (your first request)
Server responds with 401 (Access denied)
Browser gets error and sends credentials back => authenticated (your second request)
After the 3rd step, if the server has not received the requested credentials, it sends another 401 response and the browser displays the 401 error page. A more complete description can be found here.
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.