hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jake C" <buddhabu...@hotmail.com>
Subject Re: https now works, but http doesnt?!?!
Date Sat, 02 Dec 2006 17:36:40 GMT
I tried all of that.

I call "client.setState(new HttpState());" before my transactions and 
removed the synchronized blocks.

I checked the forms I'm posting to on both servers, and they are identical 
except for the __VIEWSTATE value.

I print out the URI and the parameters I'm adding. If I paste the URI into 
the web browser then add the parameters manually 
(<URI>?<Name1>=<Value1>&<Name2>=<Value2>&...) it works
just fine!

I printed out the Headers:
header[0]:User-Agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; 
.NET CLR 1.1.4322)
header[1]:Host=<host>:8080
header[2]:Content-Length=110
header[3]:Content-Type=application/x-www-form-urlencoded

The content length is exactly the right length for all my parameters and 
values, with a = between the name and value, and an & between each pair.

The Method is a PostMethod, and my URI is correct. What the heck is going 
on? Is there another level of debugging I can turn on to help track this 
down?

This is EXTREMELY frustrating! Why should it work for https and not for 
http? What could possible be the difference between the two?

Here is the rest of the information I'm printing out:
method=org.apache.commons.httpclient.methods.PostMethod
URI=http://<host>:8080/<app>/
path=/<app>/
query=null
reason=Method not allowed
status=405, Method not allowed
location=null
contentType=Content-Type: text/html

All of this is identical for the https situation except for the URI, which 
says https and has no port specified.

>From: Roland Weber <http-async@dubioso.net>
>Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
>To: HttpClient User Discussion <httpclient-user@jakarta.apache.org>
>Subject: Re: https now works, but http doesnt?!?!
>Date: Sat, 02 Dec 2006 09:06:20 +0100
>
>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
>

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces 
friends module. 
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk


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


Mime
View raw message