Everything

php

[PATCH] Passthrough MD5/SHA1 calculation of uploaded files

php.internals

David Santinoli

22 years ago

Hi,
I'm submitting a patch to perform "on the fly" MD5/SHA1 digest
calculation of a file uploaded via the HTTP POST method.  Being
not uncommon for applications to require some digest of a freshly
uploaded file, doing the math directly in the buffer where the file is
being read can save some time.

Digest calculation is triggered by setting the special input fields
COMPUTE_MD5 and/or COMPUTE_SHA1 to a non-zero value:

<input type="hidden" name="COMPUTE_SHA1" value="1">

(note that these assignments must precede the
<input type="file" name=...> field, as in the MAX_FILE_SIZE case.)

The result is found in the special variables
$_FILES[userfile]["md5"] and $_FILES[userfile]["sha1"].
These variables are only defined upon request of the corresponding
digest.

The patch was produced against the current CVS version of rfc1867.c
(PHP_5_0 branch, v1.160).

Cheers,
David

--
David Santinoli, Milano             +   <david@santinoli.com>
Independent Linux/Unix consultant   +   http://www.santinoli.com

Derick Rethans

22 years ago

On Wed, 4 Aug 2004, David Santinoli wrote:

>   I'm submitting a patch to perform "on the fly" MD5/SHA1 digest
> calculation of a file uploaded via the HTTP POST method.  Being
> not uncommon for applications to require some digest of a freshly
> uploaded file, doing the math directly in the buffer where the file is
> being read can save some time.

I like this idea, and the patch looks (from a glance OK). Without
applying it I have a question though:

Does it handle cleaning up the digest structures correctly if the
fileupload is aborted in some way?

regards,
Derick

David Santinoli

22 years ago

On Wed, Aug 04, 2004 at 05:06:45PM +0200, Derick Rethans wrote:

>
> I like this idea, and the patch looks (from a glance OK). Without
> applying it I have a question though:
>
> Does it handle cleaning up the digest structures correctly if the
> fileupload is aborted in some way?

Do you refer to the PHP_MD5_CTX and PHP_SHA1_CTX contexts?
AFAIK, given they're automatic variables with no malloc()ed buffers
inside them, it doesn't look like an explicit cleanup is needed.

Cheers,
David

PS I'm on the list!  CC:ing to my private address is unnecessary.

--
David Santinoli, Milano             +   <david@santinoli.com>
Independent Linux/Unix consultant   +   http://www.santinoli.com

Ilia A.

22 years ago

-1 it seems somewhat redundant given that this signature can be easily
generated via a single function call, md5_file() or sha1_file().

Ilia

On August 4, 2004 10:56 am, David Santinoli wrote:

Dave

22 years ago

Ilia Alshanetsky wrote:

> -1 it seems somewhat redundant given that this signature can be easily
> generated via a single function call, md5_file() or sha1_file().
>
> Ilia
>

I think his point was that the hash is calculated as the file is being
uploaded, which saves having to read the whole file a second time after
uploading is finished. For big files, and repetitious uploading, this
could probably save on the CPU cycles and I/O load a bit.

I'd like to see an ini setting to disable this, though.

Dave

Ilia A.

22 years ago

On August 4, 2004 11:16 am, Dave wrote:

> I think his point was that the hash is calculated as the file is being
> uploaded, which saves having to read the whole file a second time after
> uploading is finished. For big files, and repetitious uploading, this
> could probably save on the CPU cycles and I/O load a bit.

That is true, but to really validate the file you'd still want to check the
data you have on disk, rather then what PHP supposedly saved to disk.

Adding hidden fields (that may conflict with the ones some people already use)
also seems like a recipe for trouble.

Ilia

David Santinoli

22 years ago

On Wed, Aug 04, 2004 at 11:35:17AM -0400, Ilia Alshanetsky wrote:

> On August 4, 2004 11:16 am, Dave wrote:
> > I think his point was that the hash is calculated as the file is
> > being uploaded, which saves having to read the whole file a second
> > time after uploading is finished. For big files, and repetitious
> > uploading, this could probably save on the CPU cycles and I/O load a
> > bit.

Exactly.

> That is true, but to really validate the file you'd still want to
> check the data you have on disk, rather then what PHP supposedly saved
> to disk.

Actually, I don't see this as a way to validate uploaded files; rather,
I consider it an optimized replacement for the upload -> md5_file()
sequence.

> Adding hidden fields (that may conflict with the ones some people
> already use) also seems like a recipe for trouble.

I admit that's a good point, although I can't really see many possible
uses for a hidden field named COMPUTE_MD5 in a file upload form - I bet
those people would be glad to switch to the new facility. ;-)

The suggestion by Derrell Lipman - requesting the hash calculation
by adding an attribute to the INPUT element - has some merit, but I
don't know how viable this road is (in terms of functionalities already
present in the PHP core), and I'd also like to stick to "standard" HTML.

Cheers,
David

--
David Santinoli, Milano             +   <david@santinoli.com>
Independent Linux/Unix consultant   +   http://www.santinoli.com

Unnamed Person

22 years ago

David Santinoli <u235@libero.it> writes:

> Hi,
>   I'm submitting a patch to perform "on the fly" MD5/SHA1 digest
> calculation of a file uploaded via the HTTP POST method.  Being
> not uncommon for applications to require some digest of a freshly
> uploaded file, doing the math directly in the buffer where the file is
> being read can save some time.

It's a nice feature to be able to compute the digest on the fly.  However...

> Digest calculation is triggered by setting the special input fields
> COMPUTE_MD5 and/or COMPUTE_SHA1 to a non-zero value:
>
>   <input type="hidden" name="COMPUTE_SHA1" value="1">
>
> (note that these assignments must precede the
> <input type="file" name=...> field, as in the MAX_FILE_SIZE case.)

... this seems like a somewhat kludgy method of specifying what you want done.
Specifically, it seems kludgy to add a hidden input field with a specific
name.  (What if there are multiple type="file" input elements and only one of
them is to have its digest computed?)

A cleaner method *might* be (if you can get the information returned to you)
to add an attribute to the input element, something like:

<input type="file" digest="md5" ...>

At least this keeps the request with the element to which it applies.  It's
still a bit kludgy in that it's adding a "digest" attribute.  I suspect you'll
have trouble getting that digest attribute returned to you by the browser,
though.

I'd be inclined to keep things simple and call the digest functions in the
normal way rather than "extending" HTML syntax.

I do like the concept, though...  Hmmm...

Derrell