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.... ...folder_id=3933&rowNumbers=1%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C 9%2C10%2C......%2C246%2C247%2C248%2C249%2C250&filename1=testDoc0.txt&...... ...folder_id=3933&bimModelId=-1&action_id=62&rowNumbers=1%2C2%2C3%2C4 %2C5%2C6%2C7%2C8%2C9%2C10%2C11...%2C297%2C298%2C299%2C300&filename1= testDoc0.txt&.. 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 characters... 1,2,3,4,5,6,7,8,9,10,11,12,13.......,294,295,296,297,298,299PK)Xu7 not sure wat seems to be the problem.... nitya On Nov 18, 2007 12:37 PM, Roland Weber <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
