Ok. I'll try that. But I guess the question remains, if this isn't a
problem with the client side, is there a way to find the root cause of
the problem and fix it on the server side?
Roland Weber wrote:
Hi Paul,
2006/08/07 11:37:18:598 PDT [DEBUG] header - >> "POST
/AppWeb/MediaBatchUploadControl HTTP/1.1[\r][\n]"
2006/08/07 11:37:18:598 PDT [DEBUG] HttpMethodBase - Adding Host request
header
2006/08/07 11:37:18:598 PDT [DEBUG] header - >> "User-Agent: Jakarta
Commons-HttpClient/3.1-alpha1[\r][\n]"
2006/08/07 11:37:18:598 PDT [DEBUG] header - >> "Host:
test.xxxx.com[\r][\n]"
2006/08/07 11:37:18:598 PDT [DEBUG] header - >> "Content-Length:
3102473741[\r][\n]"
2006/08/07 11:37:18:598 PDT [DEBUG] header - >> "Content-Type:
multipart/form-data;
boundary=----------------314159265358979323846[\r][\n]"
2006/08/07 11:37:18:598 PDT [DEBUG] header - >> "[\r][\n]"
This does not look like a problem on the client side. As you can see,
the Content-Length header has a positive value over 2GB. However, a
server may be caught off guard by such a value.
In your place, I would get rid of the Content-Length header field
to avoid this problem. Derive a class from MultiPartRequestEntity
and override getContentLength() to return -1, that should do the
trick.
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.html#getContentLength()
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paul Risenhoover - Director of Engineering - DAX Solutions, Inc. - 310-478-6644
____
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message.
