When I say drop connection I mean actually closing the socket without reading any more bytes. I am trying to prevent a DoS attack where the attacker is trying to make a lot of HTTP requests that upload very very large files. For my purpose, I will consider any client trying to upload file larger than a pre-configured amount as attacker, and I would like to terminate the connection ASAP without reading even single more byte (I would like to send a HTTP 413 back to client if possible, but I don't care if the client receive the response or not, I just don't want any more byte from the client).
I have a app that runs within Jetty and from what I observed even if I throw exception, Jetty itself will still consume all the request body (and drop them) as part of the HTTP request life cycle.
So how do you guy do that? Through Jetty itself or through some kind of reverse proxy?
I know about maxFormContentSize and Apache File Upload, but they don't really do what I am looking for.
Related
I have following use case: User uploads files to Java 6 servlet (Apache 6). In order to be able to upload, he must have security token assigned. Is there a way to check this token before accepting whole request with multipart data, and possibly reject? I dont want to use unnecessary bandwith, and defend server against unauthorized access. Of course I have front end validations, but you could still get upload URL from web page and use it for DOS attack, or fill server memory to crash.
Every solution I googled stated you cannot process request before server downloads it. Is there any way to bypass this? Possibly check againts session in some filter? Or maybe I am missing some easiers solution and overthinking it.
Your problem is essentially "How will I handle a request before the request has arrived". Unfortunately that's not possible in our limited universe.
But just because the request has arrived doesn't mean the request is complete. Checking the headers before starting to stream the complete data should be quite enough to prevent any excess bandwidth being used.
So in reality you don't even have a problem.
I'm trying to implement a client application over https using commons-httpclient.
I have implemented a servlet at the server end to send data to client as blocks (chunks of data). each block contains 4MB. now my problem is, If i download using http url, i.e like http://localhost:8080/DownloadServlet/post it works fine. If I use https, some times I'm receiving 500 error and download stops in the middle. Can some one tell me what might be the problem.
thanks.
I have a third party server that is periodically sending http post request messages to an URL(can be configured). In my application I am reading data by starting a jetty server and listening for data on the configured URL.
Wondering if it is possible to listen for the data sent by the server without starting any server like the jetty?
You can always create a socket yourself and listen at port 80 (or something similar) for HTTP requests. See http://download.oracle.com/javase/6/docs/api/java/net/ServerSocket.html
But there are several problems: Theres a lot of overhead that you need to do yourself. Parse the HTTP request, extract the headers and the body and depending on the headers you need to do certain things like caching, authentication, etc. And that's a lot of stuff you need to implement. Using an existing web server is usually a better idea, since the people who wrote it (usually) know exactly what they are doing.
Another option is the Apache HttpCore library (http://hc.apache.org/httpcomponents-core-ga/index.html). You can use it to write your own Http Server... But again, there's still a lot of stuff you need to take care of ...
If you want to do it for learning purposes, go ahead and implement it yourself. When it is for production, stick with the commonly used web servers.
I'm working on a project where I have a simple ip camera that has an mjpg stream with an internal address and a web server. I would like to serve the camera's feed through my servlet so that the camera does not require port forwarding for each installation. My ideal situation would be that the user would only enter the URL for the mjpg's location (located on their network) and the servlet would handle the rest.
I'm pretty clueless on how to begin implementing this or if it's even possible as I'm not actually creating the mjpg stream myself, I'm using the one that already exists. Is there a way to do this without making an obscene amount of requests to my web server?
An additional thorn in my side is that I'm restricted to libraries that would work in J2ME.
In a servlet, you can simply inspect the HttpRequestObject for the URL, method, and probably accept header, then create an HttpURLConnection with the ip address of the appropriate camera, make the connection. When you get a response back from the camera, copy the appropriate entries from the response and set them in the ServletResponse object, and then get the camera response input stream and the output stream for the client's request and copy the bytes from one stream to another, and close everything up when you're done.
If you can deploy something like Jersey, the JAX-RS reference implementation, this would be even easier.
Ok. So you basically want to proxy several cameras to be connected to via a single servlet?
It shouldn't be too hard. You just need to open up a socket connection to the requested URL in your servlet.
Assuming you're using HTTP, if you had a request for "http://myservlet/servlet?url=http://camera_url_here", you should just be able to open up a connection to the camera URL and write the bytes received to the HttpServletResponse's Outputstream. You might want to stick your socket connections in a Map, so that you don't needlessly connect to the same camera twice. Don't forget to copy/set the correct MIME types in the HttpServletResponse object.
Have you looked at http://www.videolan.org/vlc/streaming.html ? I'm pretty sure it can already do this.
I am trying to download a file from my Java application. But because UrlConnection uses HTTP 1.1 protocol i get a Tranfer Encoding: chunked response in which case i can not find out file size(content-length is not set). From what i could find HTTP version is hard coded in the class and there is no way to change it. Is it somehow possible to change the version back to one or tell the server not to use chunked encoding when sending a file?
Edit: I am not trying to retrive dynamic content my application is a download manager.
files i am downloading are static. Other downloaders i checked wget,igetter,curl use Http 1.0 and they get the size info from most servers. But my application and firefox issuing Http 1.1 always gets chunked encoding. I understand that content-length is not always present but i would like to get it most of time.
The Jakarta Commons HTTP Client contains a "preference architecture" that allows some fine grained control over the particulars of the HTTP connection. See http://hc.apache.org/httpclient-3.x/preference-api.html
It's very likely that the server can't specify a valid content-length, even if you specify HTTP/1.0. When content is dynamically produced, the server has to buffer it all to measure its total length. Not all servers are going to be able to fallback to this less efficient behavior.
If buffering the response is reasonable, why not do it in your client, where you have full control? This is safer than relying on the server.
Read the response without processing, just stuffing the data into a ByteArrayOutputStream. When you are done, measure the length of the resulting byte array. Then create a ByteArrayInputStream with it and process that stream in place of the stream you got from the URLConnection.