Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <457133FC.60004@dubioso.net>
Date: Sat, 02 Dec 2006 09:06:20 +0100
From: Roland Weber <http-async@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.0.8) Gecko/20061110 SeaMonkey/1.0.6
MIME-Version: 1.0
To: HttpClient User Discussion <httpclient-user@jakarta.apache.org>
Subject: Re: https now works, but http doesnt?!?!
References: <BAY129-F3865B72DCC1D0FFF321641BFD90@phx.gbl>
In-Reply-To: <BAY129-F3865B72DCC1D0FFF321641BFD90@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Hello Jake,

> When I run under https, I get a log message that I used to get for http
> as well:
> [INFO] HttpMethodDirector - Redirect requested but followRedirects is
> disabled
> I was never sure WHY I got that message, as I always called
> method.setFollowRedirects(false) and follow the redirects manually.
> However, it didn't seem to hurt anything, so I ignored it.

Yes, that is not a warning. It is just an INFO message to tell you
that you called method.setFollowRedirects(false) and that you need
to follow the redirects manually :-)

> However, now when I use http, I get this message instead:
> [INFO] HttpMethodBase - Discarding unexpected response: HTTP/1.1 100
> Continue

"100 Continue" responses are part of the expect-continue handshake
you can enable for POST or PUT requests. The "unexpected" in the
message means that HttpClient wasn't using the expect-continue
handshake, or maybe that the server sent two of the "100 continue"
responses. I'm not sure whether that is just strange or actually
bad behavior on the side of the server, but it's nothing to worry
about at this time.

> I then get a 405, Method not allowed error and some really strange HTML
> as a response, which I'm sure is just the standard IIS 405 error page,
> but since it mentions protocol, I'll include it at the bottom of the
> message.

That means you are sending a POST to a URL that can only be used
for GET. Or else there is a more complicated mismatch, like if you
send a HEAD request and the server doesn't like it or some such.

> I am POSITIVE I am using the correct url. It DOES have a port, but I've
> been using this exact same code before I added the EasySSL* classes, and
> it worked just fine. If I manually browse to the same page, I can log in.

I think it is just a coincidence that this problem happens now
after you've fixed the SSL problem. Have you checked whether
somebody updated the server recently and thereby changed the
URL you need to use?

> Actually, there IS one thing I changed from before. I made my HttpClient
> static and access it in synchronized(client) blocks now. My application
> is user-bound, and one interaction is always completed before they can
> start another anyway, but I added the synchronized blocks for safety.
> That couldn't really cause problems, could it? I'm not locking up, just
> getting an error from the server.

The HttpClient object keeps a default HttpState, where cookies are
collected. Try to reset the default state before each interaction
to see whether that makes any difference.

>From a general design perspective, synchronizing access to the
HttpClient is overkill, especially because you have to synchronize
full method executions. Install a multithreaded connection manager,
create a new HttpState for each interaction instead of using the
default state, and then access the static HttpClient object without
synchronization. Make sure to shut down the connection manager
properly when it is no longer needed.

hope that helps,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org