Frequently Asked Questions

  1. Why can't I unzip the download library?
  2. What is the org.xml.sax package?
  3. Where is meterware.com?
  4. How do I use HttpUnit to test my pages that use JavaScript?
  5. Does HttpUnit support https?
  6. Can I use HttpUnit through a proxy server?
  7. Why isn't HttpUnit handling my non-English pages?
  8. HttpUnit fails with an IllegalArgumentException: sun.io.CharToByteUTF-8, what do I do?
  9. HttpUnit is not finding the buttons and parameters in my forms. What is wrong?
  10. Why do I get java.lang.IllegalAccessError when calling getResponse()?
  11. Why doesn't my servlet see parameters on a POST request?

Why can't I unzip the download library?

HttpUnit is archived using the classes in the java.util.zip package. Some older Unzip programs cannot understand this format. If you are using WinZip, stick to version 7.0 or later.

What is the org.xml.sax package?

You may be getting compile or runtime errors asking for the org.xml.sax package. This package is found in JTidy, the HTML parser used by HttpUnit. You should download Jtidy from its SourceForge download page and install Tidy.jar in your classpath.

Where is meterware.com?

When I started HttpUnit, I had a web site with the meterware.com domain, and relied on it to host some of the example code. Since then, my ISP has dropped the hosting package I was using and I have not yet signed up with another host, mostly due to lack of funds. I hope to correct this in the near future.

How do I use HttpUnit to test my pages that use JavaScript?

Unfortunately, you can't. HttpUnit does not support any dialect of JavaScript. I have been shown a JavaScript library and it is possible that I will one day add JavaScript support, but since I use it very little in my own development, and since it looks like a lot of work, it is not a major priority for me. If you feel ambitious enough to add JavaScript support yourself, I would be happy to accept submissions.

Can I use HttpUnit through a proxy server?

Yes. HttpUnit uses java.net.HttpURLConnection, so the normal Java way to use proxies will work. At some point HttpUnit may support this more directly, but for now, you will need to set the system properties yourself.

Why isn't HttpUnit handling my non-English pages?

Older versions of HttpUnit (through 1.2) incorrectly assumed that all pages were in the default character set for the client platform. As of version 1.2.1, HttpUnit correctly recognizes the charset parameter of the Content-type header which may specify an alternative character set; when none is specified, HTML 1.1 says that the character set is to be taken as iso-8859-1. Unfortunately, some HTTP servers do not send this parameter correctly, and many browsers incorrectly use this as an indication that they should determine the character set in some other fashion. To imitate this behavior, HttpUnit allows you to set the expected character set for future pages by calling HttpUnitOptions.setDefaultCharacterSet(). This setting will not apply to those pages for which the server specifies the character set.

Non-English form handling is supported as well. Any parameter values entered into a form will be encoded as the same character set as the document containing the form. The server code will then have to handle those characters appropriately. In Java, that would be converting them to Unicode with statements such as

String rawName = request.getParameter( "name" );
String japaneseName = new String(name.getBytes("8859_1"),"EUC_JP");
where the proper encoding should be substituted for "EUC_JP". The getBytes call is needed to extract the raw bytes from the parameter string.

HttpUnit fails with an IllegalArgumentException: sun.io.CharToByteUTF-8, what do I do?

JTidy requires bytes, not characters, and HttpUnit 1.2.1 sends it bytes in UTF-8 encoding, which it obtains from the input page using getBytes( "UTF-8" ). Unfortunately, Sun used the wrong encoding name in its JDK 1.1.x implementations, so this code fails under JDK 1.1. This has been corrected in HttpUnit 1.2.2.

HttpUnit is not finding the buttons and parameters in my forms. What is wrong?

This often happens when your HTML is not valid. Most browsers are extremely forgiving of bad HTML; however, JTidy (the HTML parser used by HttpUnit) is not. It expects tags to be nested according to the HTML specification and will reject any that are not. JTidy can display error messages to tell you what is wrong. To see them, call HttpUnitOptions.setParserWarningsEnabled( true ) before retrieving your HTML page. Once you have corrected any errors, HttpUnit should see your form buttons and parameters.

Why do I get java.lang.IllegalAccessError when calling getResponse()?

This happens when you use HttpUnit and certain versions of JTidy with one of the JUnit graphical test runners, which reloads classes every time to run a test. Unfortunately, this places different versions of the JTidy classes in different class loaders, so you get this error. To avoid it, you can do any of the following:

This problem appears to be resolved in JTidy r7, which is included with HttpUnit 1.4.1 or later.

Why doesn't my servlet see parameters on a POST request?

Some older servlet engines, such as Tomcat 3.1, get confused when they see a charset attribute on the Content-Type header. HttpUnit 1.2.6 sends this attribute; As of HttpUnit 1.2.7 it will only send it if you call HttpUnitOptions.setPostIncludesCharset(true) before your request.