# [PATCH] Passthrough MD5/SHA1 calculation of uploaded files

- Thread: https://externals.io/message/11910
- Original archive: https://news-web.php.net/php.internals/11910
- Started by David Santinoli on 2004-08-04T14:56:57+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #11910 — David Santinoli — 2004-08-04T14:56:57+00:00

URL: https://externals.io/message/11910#11910

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

---

## #11911 — Derick Rethans — 2004-08-04T15:06:45+00:00

URL: https://externals.io/message/11910#11911 · In reply to: #11910

>   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

---

## #11912 — Ilia Alshanetsky — 2004-08-04T15:08:20+00:00

URL: https://externals.io/message/11910#11912 · In reply to: #11910

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

Ilia


> 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

---

## #11914 — Dave — 2004-08-04T15:16:36+00:00

URL: https://externals.io/message/11910#11914 · In reply to: #11912

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

> 
> 
> > […]

---

## #11915 — Derrell.Lipman@UnwiredUniverse.com — 2004-08-04T15:25:29+00:00

URL: https://externals.io/message/11910#11915 · In reply to: #11910

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

---

## #11916 — Ilia Alshanetsky — 2004-08-04T15:35:17+00:00

URL: https://externals.io/message/11910#11916 · In reply to: #11914

> 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

---

## #11919 — David Santinoli — 2004-08-04T19:54:15+00:00

URL: https://externals.io/message/11910#11919 · In reply to: #11911

> 
> 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

---

## #11920 — David Santinoli — 2004-08-04T21:37:54+00:00

URL: https://externals.io/message/11910#11920 · In reply to: #11916

> 
> > […]

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
