Although I cannot answer your question and tell you what you are doing wrong - I can point you in a direction.
I myself am running into the same problem. I'm testing against a website that is going through an iterative cycle. Submitting forms and selecting options of HTML select controls were no problem, until I started testing against the latest code drop - I recieved the same error as you did. When digging into HttpUnit, I discovered that (on our latest code drop), the HTML form control thinks it does not have any options associated with it - even though upon inpsection of HTML document they are clearly present.
I suspect that the generated HTML form has varied enough from previous working iterations so that HttpUnit 1) cannot correctly parse the HTML document because it is an invalid HTML doc (invalid compared to the schema) or 2) it is a bug with HttpUnit.
I hope this helps - if you have found the issue or a work around, please let me know.
Thanks Ulf - the thread/link you provided on SourceForge explained the problem, how to fix it and provided several work arounds.
What is weird about this problem being centered around case-senstivity is that the Node representing the <select> form control has not changed (case sensitivity, more/less <option>s, attributes, etc.) between the iterations in which it was working and where it broke. However the HTML document and <form> node has changed - because of that the HTMLParserFactory is has flipped between returning Document types (HTMLDocment vs Document). But I don't see why this should matter as my <select> node has not changed.
I can post the two html pages if you would like to satisfy your curiosity if you like...