[HttpClient][PATCH] Test updates plus host request-header modification

[Ryan Lubke <Ry...@Sun.COM>]

I previously had 5 failures in the test-local suite (localhost and
webapp tests) and am now down to 1.  See below.

Test Failures
------------------------------------
 - TestHttpClientLocalHost.testExecuteMethod
 - TestHttpClientLocalHost.testExecuteMultipleMethods
 - TestMethodsLocalHost.testMethodsHead
 - TestWebappMethods.testPostBodyNVP
 - TestWebappRedirect.testRecursiveRedirect
------------------------------------

testMethodsHead was resolved by changing the second request from
"/index.html" to "/".  Can't make guarantees that each server will have
an index.html.  In the case of Tomcat, there is an index.jsp.

testExecuteMethod and testExecuteMultipleMethods were resolved by a
change in Host request-header logic...more on that later in the email.

testPostBodyNVP was resolved by using a later version of Tomcat (in my
case HEAD branch of TC5).  The problem appears to be that the version I
was using (outdated HEAD branch of TC4) was populating the POST request
parameters to incorrectly.  The later version of TC correctly supplied
the POST body within the InputStream.

That leaves testRecursiveRedirect.  This is still failing.  There are no
comments so I'm still trying to figure out exactly what the issue is.
The failure is ultimately due to a 404 when a 200 is expected.

As to the Host request-header issue.  There has been some debate about
this on the TC dev alias as well as in the JSR-154 EG.  It seems the
consensus is that an empty Host header is invalid.  Anyway, it's a can
of worms that I don't think is going to be resolved anytime soon.

I would like to suggest (and the attached patch to HttpMethodBase and
the associated Host request-header test reflect this suggestion)
that the Host request-header logic be relax so that if the target
resource is identified by an IP address, the IP address is used as the
value of the Host request-header...no matter if strict mode is enabled
or not.

If the logic stays as it currently is, a developer's mileage may vary.

I don't think strict compliance is worth the headache in this particular
case as all user-agents I've seen do not follow this logic.

Open to comments, suggestions, etc. as always.

-rl