On Sat, May 17, 2008 at 12:11:53PM +0300, Kalle Olavi Niemitalo wrote: > Witold Filipczyk <[EMAIL PROTECTED]> writes: > > > On Mon, May 12, 2008 at 12:14:52AM +0300, Kalle Olavi Niemitalo wrote: > >> - If something changes the size of the file while ELinks is > >> sending it, then it seems possible that the amount of data > >> posted does not match the generated Content-Length header. > >> ELinks should detect this and report an error instead of > >> annoying the server with an invalid request. (Alternatively, > >> send the POST request in chunked encoding, so that the size > >> need not be known in advance.) > > > > I skip this. It's too difficult to implement right now. > > I was looking at this but didn't actually find any Content-Length > header yet. However, there seems to be a related problem. > > encode_multipart() must add boundary strings between files. It > first uses "00000000000000000000000000000000" as the boundary; > after it has formatted all of the POST data, it then checks > whether the boundary string occurs elsewhere in the data, and > changes the boundary until it is unique. Now in big_files-1008, > this no longer works reliably, because ELinks does not read the > uploaded files during encode_multipart() and does not notice if > they contain the boundary string. > > I guess there are two options here: > > (a) Generate the boundary string from random numbers so that it > is extremely unlikely that the file contains it. To get the > random numbers, one could use gcry_create_nonce(), > RAND_pseudo_bytes(), or CryptGenRandom(), or read > /dev/urandom. Total cryptographic randomness is not needed > here, I think, but rand() seems a little too weak. > > (b) Read the files in encode_multipart() and verify that the > boundary string does not occur in them. > > In addition to these, ELinks could also check while uploading > that the file has not changed to include the boundary string. > I suppose that is not absolutely required though.
(b) is not acceptable. I chose /dev/urandom. -- Witek _______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
