I've been trying to find workarounds to this for nearly 6 straight hours now but to no avail.
I have a simple HttpUnit program that does some sign in to a website. The problem is that I'm getting this error when I finally submit the log in form:
Exception in thread "main" java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:223)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:92)
at com.meterware.httpunit.WebResponse.readFromStream(WebResponse.java:967)
..and so on..
It appears a bug in the way JDK was managing the gzip file was reported back in 2002 (!). It appears Java still has this bug and the only workaround is to tell HttpUnit to not accept gzip encoded data, like so:
WebConversation.getClientProperties().setAcceptGzip(false);
Unfortuantely this I cannot do. For the sign in to be successful, I need to have gzip enabled, otherwise I'm just redirected to the generic home page (without being signed in).
I suspect the only way to make this work would be to change the source code of HttpUnit and handle the EOF excpetion in it's gzip parsing. I desperately need help. Does anyone have a solution to this?
If not, then could you suggest some equivalently simple API in Java, such as HttpUnit, for tasks such as filling forms and signing in.
I suspect the only way to make this work would be to change the source
code of HttpUnit and handle the EOF excpetion in it's gzip parsing.
This is often a solution for developers when there are bugs in third party libraries. If you know what the problem is in HttpUnit, why not fix it locally? You can even push the fix back to the project and hope they adopt it.
If not, then could you suggest some equivalently simple API in Java, such as HttpUnit, for tasks such as filling forms and signing in.
If you mean a library to traverse websites, there are plenty. If you want a "headless" HTTP client, try Apache HttpComponents HttpClient. If you want something that actually uses a browser, try Selenium.
It seems this problem was fixed in HttpUnit 1.7 (I was using 1.6).
Anyways, I'm shifting to HttpComponents as suggested by #ShaggyFrog since now I'm running into bigger, unknown problems with cookies and sessions.
Edit: It seems HttpComponents was overly complicated. At one point I had to manually handle Http 302 redirects. So I decided to shift to HtmlUnit, which is extremely similar to HttpUnit but without any cookie or gzip problems. Worked like a charm.
Related
I'm working on a small java app that requests json data from an open online db, and I've run into the problem that the first URL has no issues having its stream opened (doesn't matter which URL I start with), but as soon as I try to use a second one I get "javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure".
I can't seem to find anything mentioning this on the internet, which seems kinda weird to me, so I wanted to actually ask how to do this properly, because I use Jackson to handle the incoming Json data, and while it has a method to just handle URLs, all that does is call openStream() which causes this problem. I'm using Java 11 for the record.
EDIT: Also forgot to mention it's a JavaFX application, if that could possibly be an issue
Thanks to #dave_thompson_085, I found out that it was an issue with Java 11.0.1 specifically, updating (to 11.0.11 in my case) solved the problem
we are having problems downloading a file from a remote server. We have a very high chance of getting a connection reset exception, although the same code works fine with other files we download from different servers.
We already tried using BufferedInputStream, but had the same problem there. That's why we switched to FileUtils copyURLToFile() method in hope that this will be a bit more robust. But that didn't improve the problem.
It seems like browsers don't have a problem downloading the file (at least it worked every time we tried), we just have the problem in Java (or Lucee using Java to be precise). Lucee's (and Railo's before that) built in functions had the same problem, that's why we started using Java in the first place. So far with no success.
Are there any ways to make this download more robust?
We also have little to no influence on the server that hosts the file, so ideally we should fix the problem on our side.
Thanks a lot!
Basically i am trying to create a websocket based live chat for a few websites i work on.
the server i have up and working no bother running on the javax.websocket package on a glassfish server.
the standard HTML5 websocket interface i also have working no bother.
the problem is that about 10-20% or our users dont use an HTML5 compatible browser so i need a fallback. Do far the best option i can find seems to be running a swf as a middle man between the websocket server and HTML. The problem there being that action script doesnt support websockets as standard so im having to write my own wrapper.
So far i can connect to the server and perform a successful handshake, i can also receive messages from the server with no issues, the problem is sending messages.
I have had a look through https://www.rfc-editor.org/rfc/rfc6455#section-5.2 at the theory of the data frame for a websocket package and written an attempt at this, i have also looked through various other open source library's without any luck. What happens is whenever i send a message to the server i get a response of
RSV bit(s) incorrectly set.
and then the connection closes (as it should with the websocket protocol).
A large part of the problem i suspect is that this is the first time i have ever even looked at action script never mind attempted using it.
i was just wondering if anyone else had been having this problem/response and preferably has found a solution
in an idea world im looking for a tutorial that i could use to actually understand the creation of the frame better but i cant seem to find one :P
thanks
Matt
As it turns out it was just one of those bizarre bugs that happened for basically no reaseon, i ended up re-writing the section of code that manages the creation of websocket frames and frame fragmentation and it just worked.
ive had a few programmers look the the two examples of code including an action script developer and none of them can work out why the one snippet works and the other doesnt.
On the upside going back over the process has given me a better understanding of the protocol. If there is anyone else that has been having a similar problem feel free to get in touch and i will see if i can help you out.
I'm having trouble testing a web app with Safari. My app returns wave audio data. The problem happens when I change the application and hit it again from Safari. Safari caches the original response so no matter how many times I hit refresh it seems like I've not updated anything. I can almost get around this using force refresh with Firefox but because I'm having trouble generating the wave headers using the javax.sound API Firefox only plays the first second of audio returned. A few weeks ago I tried setting the HTTP header in my servlet to prevent caching but I don't think I was setting it correctly. (What is the header for browser cache control?) This is becoming a real pain and I'm looking for any ideas, comments, or alternative approaches. I'm getting ready to try again but I figured I'd ask here in the interim to see if someone can provide help.
I found my answer. I just added a combination of "Pragma: no-cache", "Cache-Control: no-cache", and "Expires: -1" to y response headers. Now it appears the caching is no more. I still need a solution for my broken wave headers. I really hate to engineer a wave/io package for something that should be straight forward.
I'm trying to implement a Cometd/Bayeux server on Android using iJetty. The Jetty implementation itself works just fine serving static pages along with servlets. I am trying to up the ante a bit and create a Bayeux application on the phone but I'm having some trouble. I can hit the page that has the dojo cometd scripts on it, but I am unable to subscribe to the channel. When I view firebug/chome developer tools, I see a series of posts/gets that last a couple of milliseconds (~14). However, when I run a cometd application on a normal machine, the posts/gets last several seconds (~14 seconds) before timing out and reopening the connection. This second scenario makes sense to me with my understanding of how continuation in HTTP works. So I'm thinking that something is not allowing those connections to hang open and prematurely returning a value and consequently closing the connection. I would post my source but I'm not sure what to post short of posting everything...(it is open source though so if you want to have a look it's at http://webtext-android.googlecode.com).
So my question is, does anybody think that there could be some underlying limitation imposed by the Android system that is preventing these servlets from working? Are there assumptions that are made by the Jetty Bayeux implementation with regards to the underlying system? Or is it more likely that somehow I have a bad implementation of the ContinuationCometdServelt? I should note that all of the posts/gets from the client return 200 OK messages so I'm not inclined to think that the Android system is simply terminating the connection.
I know this is a bit off the wall and I'm definitely trying to do something a bit out of the ordinary but any suggestions or tips would be greatly appreciated.
In case anybody discovers this and has similar problems (this applies to all cometd implementations regardless of host), I discovered that the issue was with using the Google js library. For some reason, the dojo scripts I was loading from Google (1.4) didn't have a valid implementation of cometd. I switched my dojo script to the one that was used by the jetty-1.6.23 example and it works perfectly.