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.
pgpsAjCvXZwW6.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
