Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:11915 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96554 invoked by uid 1010); 4 Aug 2004 15:25:32 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 96475 invoked from network); 4 Aug 2004 15:25:32 -0000 Received: from unknown (HELO amber.vis-av.com) (66.92.75.243) by pb1.pair.com with SMTP; 4 Aug 2004 15:25:32 -0000 Received: (qmail 30799 invoked from network); 4 Aug 2004 15:25:31 -0000 Received: from unknown (HELO random.?none?) (192.168.1.9) by amber.internal with SMTP; 4 Aug 2004 15:25:31 -0000 Received: (nullmailer pid 28205 invoked by uid 0); Wed, 04 Aug 2004 15:25:30 -0000 To: David Santinoli Cc: internals@lists.php.net References: <20040804145657.GA15294@astrid.santinoli.com> Reply-To: Derrell.Lipman@UnwiredUniverse.com Date: Wed, 04 Aug 2004 11:25:29 -0400 In-Reply-To: <20040804145657.GA15294@astrid.santinoli.com> (David Santinoli's message of "Wed, 4 Aug 2004 16:56:57 +0200") Message-ID: <1xin53iu.fsf@random.internal> Lines: 40 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [PHP-DEV] [PATCH] Passthrough MD5/SHA1 calculation of uploaded files From: Derrell.Lipman@UnwiredUniverse.com David Santinoli 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: > > > > (note that these assignments must precede the > 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: 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