On Wed, 2003-02-26 at 22:00, Simon Roberts wrote:
> I just wrote a testcase that uses plain httpclient/jetty, and it doesn't
> exhibit the problem. (Though is a lot simpler than my application). Could
> it be related to SSL (which my application uses)?
>
Hhmm. Interesting. It was reported earl
PROTECTED]>; "Aurelien Pernoud"
<[EMAIL PROTECTED]>; "Simon Roberts" <[EMAIL PROTECTED]>
Sent: Wednesday, February 26, 2003 10:25 PM
Subject: Re: HTTP Post and HTTP/100 (continue)
> Simon, Aurelien, Ingo
>
> Please help me help you.
>
> I seem unable
Sorry Oleg,
Stunnel is an SSL wrapper, see www.stunnel.org.
Using Stunnel you can tunnel a http connection to another host while
simultaneously encrypting it.
Ingo
> Ingo, pardon me. What is stunnel-4.00 exactly?
> Oleg
>
> On Wed, 2003-02-26 at 09:51, Ingo Brunberg wrote:
> > I have the same pr
; I get the same problem with HTTP PUT.
> > >
> > > Adding
> > >
> > > method.setUseExpectHeader(false);
> > >
> > > seems to fix it.
> > >
> > > Cheers, Simon
> > >
> > >
> > > - Original Mess
Well as far as i've looked now, it seems my trouble (parsing HTTP/) doesn't
come only with Post method, but also with Get Method...
Attached is a log of 3 GET requests, always the same, and this bug I'm
totally unable to reproduce outside of my webapp, and I'm looking why.
The first one goes ok,
lient Project" <[EMAIL PROTECTED]>
> Sent: Wednesday, February 26, 2003 11:31 AM
> Subject: Re: HTTP Post and HTTP/100 (continue)
>
>
> > Simon
> > There's only one possible cause of the problem I can think of at the
> > moment is not flushing the output s
--
> > From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
> > To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
> > Cc: "Simon Roberts" <[EMAIL PROTECTED]>
> > Sent: Tuesday, February 25, 2003 10:18 PM
> > Su
I'm on Windows 2000 Pro, Sun JDK 1.3.1
Simon Roberts a écrit :
> Windows XP, Sun JDK 1.4.1_01
>
> From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
>
>> Simon
>> There's only one possible cause of the problem I can think of at the
>> moment is not flushing the output stream. If my assumption proves
thod.setUseExpectHeader(false);
>
> seems to fix it.
>
> Cheers, Simon
>
>
> - Original Message -
> From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
> To: "Commons HttpClient Project"
> <[EMAIL PROTECTED]>
> Cc: "Simon Roberts&
Windows XP, Sun JDK 1.4.1_01
- Original Message -
From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Wednesday, February 26, 2003 11:31 AM
Subject: Re: HTTP Post and HTTP/100 (continue)
> Simon
&
D]>
> To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
> Cc: "Simon Roberts" <[EMAIL PROTECTED]>
> Sent: Tuesday, February 25, 2003 10:18 PM
> Subject: Re: HTTP Post and HTTP/100 (continue)
>
>
> > Simon
> > I'd really ap
);
seems to fix it.
Cheers, Simon
- Original Message -
From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Cc: "Simon Roberts" <[EMAIL PROTECTED]>
Sent: Tuesday, February 25, 2003 10:18
This shouldn't be a problem for a couple of reasons:
- HttpMethodBase.reponseConnection will get set to null by
responseStream.close()
- Calling HttpConnection.releaseConnection() multiple times on
connections created by the MultiThreadedHttpConnectionManager is okay.
these connections are w
That patch looks good, but for one bug I believe it would cause (and I *may*
be wrong here):
As far as I can tell, it would cause
HttpConnectionManager->releaseConnection(conn) to be called twice for conn,
assuming that there was a responseStream set.
In the case that MultiThreadedHttpConnecti
Simon
Please try these settings. This should prompt commons-logging to use
SimpleLog instead of Log4J, which does not support TRACE verbosity.
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug
-Dorg.apache.
>> BTW, I think you should remove the log "enter
>> HttpConnection.responseAvaliable()", cause I have like 50.000 lines of it
in
>> my log for only one request... :/
> As to excessive noise in the logs, try using "debug" verbosity instead
> "trace" one.
I know logging is really useful sometimes,
What is moreover a trouble is that the connection wasn't released after the
failed post. Indeed as I call method.releaseConnection() and that response
Inputstream is empty, I didn't see anything like
HttpConnectionManager.releaseConnection: Release connection for
[EMAIL PROTECTED]
after that requ
Aurelien
The log is missing. Please try posing it one more time with carbon-copy
to my address
Oleg
On Tue, 2003-02-25 at 18:09, Aurelien Pernoud wrote:
> Ok I'll try it without the "Expect:" header tomorrow. But what I can surely
> say is that I didn't stress Tomcat, I was alone making single re
Hmm, looks like my attachment was removed...
Here it is zipped ?
I send it to you personnaly as well Oleg, in case :)
Aurelien Pernoud a écrit :
> Ok I'll try it without the "Expect:" header tomorrow. But what I can
> surely say is that I didn't stress Tomcat, I was alone making single
> reques
Ok I'll try it without the "Expect:" header tomorrow. But what I can surely
say is that I didn't stress Tomcat, I was alone making single requests on
it, not even simultaneously. Of course the logging did stress a little, as
it logged like 4MB in 30 seconds...
I've attached a log more precise on
Aurelien, it looks like you have stressed Tomcat to a point that it
failed to respond to post requests within 3 sec. Just for a heck of it,
try disabling Expect: 100-continue handshake and see if that makes any
difference.
The problem with connection not being released is troubling. You should
fi
Oleg Kalnichevski a écrit :
> Aurelien,
> Something is fishy about your setup. I have developed "100-continue"
> handshake support for HttpClient using Tomcat 4.1.18. It does handle
> 100-continue correctly. I may need to see the complete log of yours in
> order to figure out what is going on the
Aurelien,
Something is fishy about your setup. I have developed "100-continue"
handshake support for HttpClient using Tomcat 4.1.18. It does handle
100-continue correctly. I may need to see the complete log of yours in
order to figure out what is going on there. The only theory I can come
up with a
Sorry the fiest mail went out too soon...
I'm using Tomcat 4.1.18, and my log for Turbine is set to debug (not that
crazy ;)), but httpclient is either logging everything, either nothing...
very weird. I'll have to look further into it sometime.
What you say is weird (to me), I have another line
I'm using Tomcat 4.1.18, and my log for Turbine is set to debug (not that
crazy ;)), but httpclient is either logging everything, either nothing...
very weird. I'll have to look further into it sometime.
What you say is weird, I have another line where my post went ok :
Oleg Kalnichevski a écri
Aurelien
This is the expected behavior with non-compliant HTTP servers. The HTTP
server apparently does not respond with 100-continue as expected.
HttpClient resumes sending the request body after 3 second timeout. What
HTTP server are working with? It appears to have issues with HTTP 1.1
spec comp
Here is stuff I got from a Post Method, after removing the log of method :
[25 févr. 2003 16:05:31 DEBUG] - >> "User-Agent: Jakarta
Commons-HttpClient/2.0alpha2
" [\r\n]
[25 févr. 2003 16:05:31 DEBUG] - >> "Host: localhost:8080
" [\r\n]
[25 févr. 2003 16:05:31 DEBUG] - >> "Cookie: $Version=0;
JSE
I'm sorry I have trouble enabling wire log within my webapp. I'm using
Turbine and in fact it seems HttpClient took the setting from turbine to log
it's info.
I can't find an easy way to enable wirelog in a specific file... I'm not
used to commons logging.
Aurelien Pernoud a écrit :
> Sure, I'l
Sure, I'll try to reproduce it with wire log, as it doesn't happen on every
request :((
Oleg Kalnichevski a écrit :
> Aurelien,
>
> Same request. Could you please produce a wire log of the HTTP
> communication that causes the problem you mentioned?
>
> Oleg
-
Aurelien,
Same request. Could you please produce a wire log of the HTTP
communication that causes the problem you mentioned?
Oleg
On Tue, 2003-02-25 at 11:17, Aurelien Pernoud wrote:
> Hey that may be the trouble I'm meeting too and I assumed it to be related
> to MultiThreadedHttpConnectionMan
Hey that may be the trouble I'm meeting too and I assumed it to be related
to MultiThreadedHttpConnectionManager...
Cause the test case I've made locally uses easy post method, and goes fine,
but in my apps there are sometimes large post, and maybe they uses the
HTTP/100 as I saw this in log :
[2
Simon
I'd really appreciate it if you could send us the debug trace for
analysis. Please refer to the following url for instructions on how wire
log can be activated:
http://jakarta.apache.org/commons/httpclient/logging.html
Your problem should be easily solvable by disabling "100-continue"
hands
Gidday,
This is probably a dumb-user question, but if it is, then it might need to
be documented for other dumb users :)
I just checked out the latest CVS HttpClient and tried it with my
application (it's using HEAD from a month or two ago), and am having a
problem.
Our app does HTTP POST (to a
33 matches
Mail list logo
