hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nitya vyas" <nitya.v...@gmail.com>
Subject Re: Problem with MultiPartPostMethod when long string added in parameter
Date Wed, 21 Nov 2007 05:48:03 GMT
Hi roland,

Its true that it can be avoidable but as we have same server code and we
need to reuse it so i ll have to stick with this approach... Deadlines take
priorities.... :)

I checked the wirelog of the post request and i found no problem in that...
heres the request for the 250 and 300 files respectively....



Heres wat i get on server side.. i m not able to copy the full length of
string in eclipse....but still i m copying it.. I can see the paths of the
files i m trying to upload also in this string.. with many other


not sure wat seems to be the problem....


On Nov 18, 2007 12:37 PM, Roland Weber <ossfwot@dubioso.net> wrote:

> nitya vyas wrote:
> >
> > The problem i am facing is that i have a String parameter which will
> store
> > number of files being uploaded in comma separated string.. 1,2,3,... etc
> Why would you do that? If it's just all numbers from 1 to n,
> then send n instead and let the server interpret that.
> In general, you cannot assume that a server will be able to
> process parameters with arbitrary length, or that all browsers
> will be able to generate them. Limits are implementation specific.
> > The value which i get for the long string parameter 1,2,3,4,5.. upto 300
> is
> > not got properly and there are garbage values in that...
> Can you be more specific about the garbage values?
> Something like line breaks?
> > wat can be done to get the value of the long string correctly by
> > parseRequest on server??
> I suggest you use the wire log on the client side to get the
> exact value that is sent for the parameter. Compare something
> that works (...200) with one that fails (...300). Then we can
> check whether what we send is comopliant with the spec.
> As mentioned above, the best way to fix this problem is to
> avoid excessively long parameter values.
> hope this helps,
>  Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message