I'm using a jetty server to handle http requests. I would like to know if there is any way I can check if the response is successfully sent back to the client. Is there an error code or status that I can check, or an exception I can catch if the transfer to the client failed for any reason?
Thanks
Is there an error code or status that I can check, or an exception I can catch if the transfer to the client failed for any reason?
It sounds like you want the server to be able to know if the response was delivered completely to the client.
The simple answer is there isn't a way to know this. TCP/IP doesn't support this, HTTP does not support this, and the Servlet APIs don't support this.
In some circumstances, an exception may be throw if the server notices that the client has closed the connection early. But there are no guarantees that it will notice, or that it will result in an exception that will be visible to the application servlet code. Indeed it is quite likely that the close won't be noticed (if at all) until after the servlet call has returned.
If you want to implement some kind of "response delivered" acknowledgement for web pages, you could embed some "onload" Javascript in the webpage that sends an AJAX request back to the server. But then you have to consider the case where the user has disabled Javascript, or the original request was made by a non-browser application.
Related
Can somebody recommend the best way to simulate web service when it's unavailable. Is there a framework, able to record and notify the users when the web service is inaccessible ?
Thanks !
I've developed demos which have a failover in case of a 400 or 500 error code on the service response (due to lack of connectivity or firewalling on the customer side network). Basically, it has to be on the client code, though, where the logic parses the response and if it encounters unexpected/bad responses, has a default scenario to handle that situation.
It's not something I've done in production, but it does save some embarrassing situations in a skunkworks projects where your main application server is down or not responsive.
I saved the request of the client (soap request) in the database (byte array) , and saved the soap response also (if there is already a response). So, when the web service is unavailable, I search the last response existing in the database, which corresponds the request. If the remote service is not yet in operation, I used SoapUI API to generate a default response.
See also:
MockResponse
I am trying to clear the HttpSession if the consumer close the browser window. I dont know how to do it, Please help me anyone
Thanks & Regards
Chakri
If you could get the browser to (reliably) notify the server that the user had closed the window, then the server could call session.invalidate() as per the original Answer provided by ejay_francisco.
The difficulty is getting the notification to happen reliably. There are various ways to detect the window close; e.g. as covered by these Questions (and similar):
Trying to detect browser close event
javascript to check when the browser window is close
javascript detect browser close tab/close browser
You could then write the (javascript) close event handler to send a specific request to the server.
However, I don't think any scheme is going to be able to deal with cases where the user's browser dies, the user's machine is shut down, and similar scenarios. So if you need the session to be cleared 100% of the time, then you are probably out of luck. I don't think it can be done.
It can be archived in a little diffrent way.
use a javascript event known as "window.onbeforeunload"
e.g
window.onbeforeunload=mylogic_function();
function mylogic_function()
{
window.location.href = "path to the servlet which inavalidate the session";
}
Have a dedicated servlet which job is only to deactivate the session
Try this ..hope this will work
EDITED :
try reading the answer on this Page
"HTTP is not a continuous-conversation protocol where the client connects to the server and they trade information asynchronously until
the client disconnects.
Instead, each HTTP client request acts like it logs in, does one
thing, then logs out. This request/response cycle repeats until the
client stops sending requests.
At NO time is the server allowed to send a response to the client
unless it's in response to a specific actual request and only one
response is permitted per request.
So you cannot have a server post a "you timed out" page to the client.
The closest you can get is to respond with a "you were timed out"
response page if/when the client makes a request.
The other common thing people want to do is to notify the server that
the client has closed a browser, window, or tab. There is no protocol
defined for the World Wide Web to deal with that. If the user closes a
server window/tab, the server is not notified by the client. Since
there is no ongoing session to be dropped (remember, the connection
only lasts long enough for the server to accept a request and return a
response), there's no way the server will know that the client went
away."
SUMMARIZATION :
YOU CAN'T DO IT
Possible Workaround :
You simply need to rely upon the session timeout. The timeout could happen at any time and you cannot even know if the user is even looking at one of your pages when it occurs. It's likely they're off looking at videos of kittens at the time.
Short answer: you can't. Fortunately, sessions expire automatically after a period of time; check your servlet engine documentation to see how to set this timeout period.
I felt that there should be a way to do it from JavaScript; unfortunately, JavaScript doesn't seem to have an onWindowClose handler.
if you close the browser it is already clear the session
but if you want to force to clear the session
usesession.invalidate();
or if you want to remove specific session use session.removeAttribute("<sessionName>");
For an assignment, I have written a server that services HTML files and I am supposed to use my web browser as a test client. I am also told that if there is a request for a file that doesn't exist i should send the following
HTTP/1.1 404 Not Found\r\n\r\n and if anything else goes wrong
HTTP/1.1 500 Internal Server Error\r\n\r\n"
I have run tests that should cause those to be sent, but nothing occurs in my browser window? Should I be getting any visual feedback from sending such a request?
In an HTML response there should only be one CRLF (carriage return and line feed) after each line. So you can first remove the extra \r\n.
Also on the second line you can send an HTML response back to the client saying what the error was if you want to show an error. This is normally what a typical web server does where it has its default error page if one is not defined. If you are not sending any HTTP headers, then you can insert the HTML body you want to send back such as <h1> No page found</h1> as the second line.
To include an "entity" in an http response
HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 10
01234576789
each line is ended by CRLF. Be sure to count the Content-Length correctly.
I see that this is a learning exercise, and understand that you may have been told to implement the server this way. But bearing that in mind ...
This is the wrong way to implement a web server / service. The right way is to find an existing implementation and build your service on top of that.
You could use a Java EE web container; i.e. something that implements the Servlets spec.
You could use a non-servlet framework (like Grizzly).
You could build on top of a server-side HTTP protocol stack; e.g. using Apache the HttpComponent library.
Building a web server from the ground up is a lot of work if you are going to do it properly. And the chances that you won't do it properly; i.e. you won't implement your service according how the HTTP spec says a server should behave. You will leave things out, do things the wrong way, etc.
Please don't do it. There are already too many broken (i.e. non-compliant) web servers out there. We don't need more.
And if you DO decide to implement HTTP from the ground up, then you (YOU) need to thoroughly read and understand the HTTP spec. And you (YOU) need to do your own basic research on how browsers implement the client side of the spec ... and what you therefore need to do on the server side to make browsers behave "normally".
I am developing a software which will be communicating with a server using HTTP (but it is not a web browser). Since the server part is not ready yet, I would like to debug my client software by sending HTTP messages to it. I know that I can send HTTP requests using Curl. But I am not sure if that is sufficient here.
I'm imagining an environment where I send a request from my application, check that it is correct using Wireshark and then reply to the request using some software. Using Curl, I think I would have open a listening port..?
I'd use a simple node.js server for this. You can write your own HTTP server in a few lines of code an simulate various return codes, response headers or response entities easily: http://nodejs.org/
PS: There are proxies that simply print out the HTTP messages. This might be helpful for you too, because you don't have to deal with WireShark anymore just for HTTP-level logging.
You can't do that with cURL. It is an http client, not a server.
The simplest way to do this is to actually implement a mock server application that just returns a static (i.e. hardcoded) message every time. You can do this using any server-side language you like (php, python, ruby, ...), or, you can even do it without a server side language, using just static files served by a webserver such as apache or nginx.
For example, if the server part (the API) would respond to /articles.json with something relevant (a JSON object containing some articles), you could put a file named articles.json that contains some hand-written data in your server's root. Then, your application would think it's calling an API when it's actually just downloading a static file.
You can use firebug addon of firefox browser to see content of HTTP request/response.
It does't require any server (but of course, if you dont have server which process requests from browser and send responses to browser, you 'll always see response "unable to connect").
If you still need to mock response, you can create simple server which is able to respond with mock responses, for example java servlet at tomcat server, with code like this:
public class MyMockServlet extends HttpServlet {
..
private String mockHeaders = "...";
private String mockResponse = "my response";
public void service(HttpRequest request, HttpResponse response){
setHeaderAndBodyInResponse(response);//your method
}
}
Is it possible to send "100 Continue" HTTP status code, and then later some other status code after processing entire request using Java Servlet API (HttpServletResponse)?
I can't find any definitive "No" answer, although API doesn't seem to support it.
I assume you mean "100 Continue".
The answer is: no, you can't (at least not the way it's intended, as provisional response). In general, the servlet engine will do it automatically, when the request requires it. Of course this makes it impossibe for the servlet to prevent sending the 100 status -- this issue is a known problem in the Servlet API, and has been known for what feels like eons now.
I know that Jetty will wait until getReader() or getInputStream() is called before it sends a 100. I think this is the behavior you are looking for. I don't know what Tomcat does.
Did you mean to ask How do I send a status code before the complete request is received, to interrupt an in-progress request due to a missing header field? It seems that's not possible with standard servlets.
What server are you using?
Some server's servlet extensions may allow this, e.g. Tomcat's Comet servlet might send EventType.BEGIN once the headers are available to process, which may allow you to interrupt a PUT that doesn't have the correct authentication.
Alternatively your server might have a plugin to reject requests based on headers.
Do you mean status code 100 ?
The API does support sending SC_CONTINUE.