Re: Generated spool file okay to copy after parse?
Joe Schaefer wrote: [...] Maybe :-). The internal behavior of the spool brigades is something we need to work on from the httpd-side, since they have slightly different needs. I want to see our spool buckets become a bit smarter: right now mod_apreq2 is creating multiple spool files when it could (in principle) consolidate them into a single file. The safest thing for you to do right now is to write copy the brigade to a separate file. You shouldn't peek inside the brigade to look at the bucket types yet; ideally we'll provide another utility function to intelligently write the spool brigade to a file (here's my +1 for a patch to apreq_util.[ch] that adds an apreq_brigade_copy_to_file function). I'm not sure I like the idea of spooling the files to a tmp file just to copy them to another tmp file, which will ultimately be copied to another file by the script writer. Imagine this cost with a 500Mb file. My next idea is to create a hook to siphon off all the brigades for file params and write to the tmp files myself. This way, I'm using the libapreq api and not presuming what the internals do... How's that sound? -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
Re: Generated spool file okay to copy after parse?
Joe Schaefer wrote: [...] Certainly doable, but I think it'd be overkill. We deal with these exact same issues (by cheating and peeking at the spool bucket implementation) in the perl glue, so having a common C API makes the most sense to me. I don't claim expertise at understanding the Perl glue, but you might have a bug on your hands for the Apache2::Params::upload_link() function. If the brigade limit was set during parsing such that a file upload brigade contained heap buckets and a spool bucket at the end, then upload_link() looks like it may just copy the spool bucket, ignoring the heap buckets. Regardless, since libapreq already exposes the spool bucket file via the api call apreq_brigade_spoolfile(), plus the fact the the Perl glue uses it, I think it's a safe bet that the api will support some sort of access to the tmp file created in the future. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
Re: Generated spool file okay to copy after parse?
Jeffrey Horner [EMAIL PROTECTED] writes: Since I set the brigade limit to 0, libapreq will generate a brigade with 1 spool bucket for each file param uploaded. Poking through the libapreq code and the apr code, I see that on UNIX that writev() is called to ultimately write to the spool file. Can I reasonable assume that it's okay to expose that spool file name to my script engine to allow code to copy that file to another location? Maybe :-). The internal behavior of the spool brigades is something we need to work on from the httpd-side, since they have slightly different needs. I want to see our spool buckets become a bit smarter: right now mod_apreq2 is creating multiple spool files when it could (in principle) consolidate them into a single file. The safest thing for you to do right now is to write copy the brigade to a separate file. You shouldn't peek inside the brigade to look at the bucket types yet; ideally we'll provide another utility function to intelligently write the spool brigade to a file (here's my +1 for a patch to apreq_util.[ch] that adds an apreq_brigade_copy_to_file function). BTW - the whole apreq_param_t and apreq_value_t code is pretty sweet. Glad you like it ;-) -- Joe Schaefer
