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
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
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
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,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13463.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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;
Hopefully the last release candidate for alpha3, rc4, is ready:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
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
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
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 at
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 there.
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
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
+1
Jeffrey Dever wrote:
Propose to promote the current 2.0 Alpha 3 release candidate 4 to the
offical release of 2.0 Alpha 3. The next release will be 2.0 Beta 1
which will commence after all Beta 1 targeted bugs are closed.
+1 yes
+/- 0 abstain
-1 no
Folks
I am currently working on a patch enabling HttpClient to handle
cross-site redirects.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
In order to lay foundation for this capability I needed to make quite a
few changes to HttpClient HttpMethodBase. I have opted for a more
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
We are now back in the Beta 1 development phase. There are currently 14
outstanding issues to tackle before we can drop another release. Work is
going extremely well. Great thanks to everyone that was involved!
We should be addressing the beta 1 bugs before other issues. I think
that we can
Completely agree. A few months ago we have been discussing possibility
of splitting HttpMethod into HttpRequest/HttpResponse pair once we get
2.0 is released. I would wait with more radical changes till then
Cheers
Oleg
On Tue, 2003-02-25 at 21:38, Sam Maloney wrote:
Makes sense to me,
I
I definitely think this is a good idea. HttpMethodBase is too big. I'm
wondering if this is too much of a change for 2.0 though. It will
require quite a few changes for users.
On a related note, when you implement the redirection handling I would
suggest removing the use of the URL class.
Mike
I share your concerns, but the work on it has been blessed by Jandalf.
Besides, I see no way of providing cross-site redirects while
maintaining full compatibility with the existing HttpClient.
Important question. Do you think that the patch will play well with your
connection pooling stuff?
Attached is a log of my application (log4j, with most of the
HttpConnection.isResponseAvaliable messages removed)
BTW: typo in method name
The interesting bit is that it times out (3 seconds) rather than getting the
100-continue response. Then, after it has send the body, the 100-continue
Did Oleg's work on the redirect made it to alpha3 rc4?
Oleg Kalnichevski wrote:
Folks
I was going to start working on it today. If there are any other takers,
please let me know
Cheers
Oleg
On Mon, 2003-02-24 at 07:27, Jeffrey Dever wrote:
This is currently on the todo list. Refer to the
Oleg,
Great that you are taking on this work. I have both general and
specific comments.
General:
* I share other's concerns with restructuring too much. At the risk
of causing you much pain (since I'm not the one implementing!),
how about the following: Create a new interface
No. Its still preliminary.
Jesus M. Salvo Jr. wrote:
Did Oleg's work on the redirect made it to alpha3 rc4?
Oleg Kalnichevski wrote:
Folks
I was going to start working on it today. If there are any other takers,
please let me know
Cheers
Oleg
On Mon, 2003-02-24 at 07:27, Jeffrey Dever
Michael Becke wrote:
I think it would be possible to add cross site redirects at the
HttpClient level without removing the other functionality from the
HttpMethod. HttpClient would just need to check the status code and
re-try. But, just because it is possible doesn't mean we should do
it.
I'm using a MultipartPostMethod to upload a file to a servlet:
File file = new File(strUrl);
HttpClient client = new HttpClient();
HostConfiguration hostConfig = new HostConfiguration();
MultipartPostMethod mpPost = new MultipartPostMethod();
hostConfig.setHost(someURL.getHost(),
As I mentioned in a previous posting (Subject: MultipartPostMethod Holding File Stream
Open?), I'm using the MultipartPostMethod to upload a file to a servlet. Here is the
example code that I included in the other posting:
File file = new File(strUrl);
HttpClient client = new HttpClient();
To implement this feature (full redirects), there are really only three
general choices that make sense:
1) augment HttpMethodBase.execute()
Pros: current functionality is maintained
Cons: makes complex code more complex,
2) have two stage redirection done partially in HttpMethodBase and part
This is an intermediate alpha release. The build process used in the
previous Alpha 2 changed from generating 4 build artifacts to a single
distribution. This one zip contains everything: all the source, the
binary jar, the logging dependancy, generated javadoc and required build
files for Ant
29 matches
Mail list logo
