httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Client Authentication POST Problem (fwd)
Date Wed, 29 Dec 2004 20:16:16 GMT
At 11:32 AM 12/29/2004, you wrote:
>"William A. Rowe, Jr." <> writes:
>> Interesting; yes it makes sense to refactor the tempfile logic
>> from the parsing logic.  The parser can still use file buckets,
>> but instead of the entire file contents, it introspects just a
>> specific range of bytes (or multiple ranges of bytes) in that
>> temp file.  So if we had two mime 'files', A and B, the apreq2
>> contents for A and B would be offset/size pointers into the
>> single tempfile.  IIUC, today, apreq2 creates 2 temp files for
>> the two different mime bodies.
>+1.  Changing apreq to share a common file bucket wouldn't be a 
>simple thing, 

Common file, multiple tempfile buckets (each with an offset/len
into that tempfile).  You couldn't continue to share a 'bucket',
each bucket should be one discrete data stream.

>because certain functions in the perl api expose the 
>spool file's name, and people are expecting that to be per-upload
>and hard-linkable.  

That's very, very nonportable.  Put your 'download' on a different
volume than the tempfile, and bam - broken.

>Not a showstopper though, it'd just a bit more 
>work within the perl glue to support the kind of optimization you're 

The mime 'contents' bucket would still potentially be encoded text.
To translate to raw data may require a 2nd tempfile, and if that's
what the user wants, modperl can and should continue to provide such
an interface (in the mime body decoding features) along with the
target path, so troublesome hardlink configuration isn't needed.

View raw message