Hello Odi,
please keep in mind that Samuel just had to change his
code in the opposite direction to make it work without
your patch...
Up until now, everyone instantiating a secure socket
factory uses that type to invoke the constructor for the
secure protocol. But I agree with Mike that there
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Kaufmann, Scott wrote:
I'm using 2.0-rc2 of http client to mimic a form based application.
Everything works fine until the Content-Length of my post gets above ~45K.
Then I get an IIS 4.0 genereated 500 Server Error with the response body
reading:
htmlheadtitleError/title/headbodyNot enough
Scott,
Try using chunk-encoding and see if makes any difference
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/EntityEnclosingMethod.html#CONTENT_LENGTH_CHUNKED
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Yong,
You should be using PostMethod.setRequestBody(InputStream) method to provide the
request content body (as Mike pointed out) and wrap the source InputStream with a
FilterInputStream. Exactly what you choose to do in the FilterInputStream is up to
you. One possibility is to file events
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] wrote:
Odi has a point here. There is no reliable way of telling where one response
body ends and another one starts, if content length information is messed up.
That's why the Content-Length header is part of the HTTP 1.1 protocol in
the first place.
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] wrote:
Agreed.
In other words, can we assume that reusing the HTTP connection is
unreliable/should be avoided if there are more bytes available than specified
with Content-Length?
In this case, at least, I would suggest to close the current connection and
open a fresh
Am Dienstag, 11. November 2003 12:32 schrieb Ortwin Glück:
[EMAIL PROTECTED] wrote:
Agreed.
In other words, can we assume that reusing the HTTP connection is
unreliable/should be avoided if there are more bytes available than
specified
with Content-Length?
In this case, at
Am Dienstag, 11. November 2003 12:32 schrieb Ortwin Glück:
[EMAIL PROTECTED] wrote:
Agreed.
In other words, can we assume that reusing the HTTP connection is
unreliable/should be avoided if there are more bytes available than
specified
with Content-Length?
In this case, at
In other words, can we assume that reusing the HTTP connection is
unreliable/should be avoided if there are more bytes available than specified
with Content-Length?
Christian,
Again, there's a similar problem. How long do you think we should wait on a connection
to be really sure that
Am Dienstag, 11. November 2003 13:01 schrieb Kalnichevski, Oleg:
In other words, can we assume that reusing the HTTP connection is
unreliable/should be avoided if there are more bytes available than
specified with Content-Length?
Christian,
Again, there's a similar problem. How long do
Christian Kohlschütter wrote:
In this case, at least, I would suggest to close the current connection
and
open a fresh one.
This is the pragmatic way of solving the problem. It always works and is
very reliable. But it is expensive.
btw, what do you mean with expensive?
Expensive: Throwing
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=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Can we assume that reusing the HTTP connection is unreliable/should be
avoided if there are more bytes *INSTANTLY* available than specified with
Content-Length
Instantly means without waiting/blocking, so at least for this situation, a
simple workaround would be feasible.
Christian,
On Tuesday 11 November 2003 13:44, Ortwin Glück wrote:
Expensive: Throwing away the (known bad) connection and opening a new
one, is a performance hit of course.
Sure. But this happens only if we detected a connection to be bad, and then it
is a very rare situation.
In strict mode, the
In strict mode, the detection of bad connection should cause an exception to
be thrown, instead of reopening another connection. What do you think?
Sounds reasonable.
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Eric,
Just to clarify things: there's strongno way/strong we touch 2.0 branch for any
other reason but fixing a strongserious/strong bug.
As far as I am concerned the suggested patch is an enhancement, and not a bug. If any
of my comments were interpreted otherwise, I offer my apologies. It
Oleg,
No apologies needed. As far as I'm concerned, your opinions with
respect to HttpClient carry far more weight - I seem to contribute a
patch about once every three months (and Mike just did a much better
rewrite of my latest patch), but otherwise just stir up trouble on the
mailing
The only additional thing to change is HttpConnection.WrappedInputStream, as
it currently lacks an available() method call to the underlying stream.
Problem fixed. WrappedInputStream now overrides InputStream#available
method. Thanks.
Oleg
Hi Oleg, Mike,
Thanks a lot for your reponse. I think I got the basic idea about your suggestion, but
more questions :-)
1. I'm actually using putmethod, not postmethod, but I assume your suggest applies to
putmethod too, is it correct?
2. Since my put will put (upload) a local file onto
Figured it out. Needed to use setStrictMode(true). Seems to be working
now. Thanks for the suggestions.
Scott
-Original Message-
From: Kaufmann, Scott
Sent: Mon 11/10/2003 3:07 PM
To: [EMAIL PROTECTED]
Cc:
Subject: 500 Server Error from IIS 4.0 with large Content-Length
I'm
Hi Yong,
1. I'm actually using putmethod, not postmethod, but I assume your
suggest applies to putmethod too, is it correct?
Yes, the same thing will work for both methods.
2. Since my put will put (upload) a local file onto server, so I
think ProgressInputStream will take a FileInputStream as
Hi,
i'm working on a so called ProxyServlet which uses the Information
provided by the ServletContainer to deliver the Requests to another
Web-Server.
At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...)
and HttpClient.execute() to deliver the Requests to the other
That's great, thanks a lot Mike.
Yong Chen
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 4:34 PM
To: Commons HttpClient Project
Subject: Re: file upload (PUT method) progress report
Hi Yong,
1. I'm actually using putmethod, not
Hi Sven,
Regarding the thread safeness, I suggest try using
MultiThreadedHttpConnectionManager. Instance it and put into
HttpClient's constructor.
Regards.
Andreas
On 12 Nov 2003 at 1:55, Sven Köhler wrote:
Hi,
i'm working on a so called ProxyServlet which uses the Information
provided by
33 matches
Mail list logo
