Re: Big files upload

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.

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILqFnHm9IGt60eMgRAldVAJ44gYltNusBzap4B5KtPJ8a27wa8gCfSyF6
VVDJgxvQOqNe4z1JQ8AcWj4=
=ZrBS
-----END PGP SIGNATURE-----