At 10:15 AM 12/29/2004, Joe Schaefer wrote: >"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > >[...] > >> HTTP/1.0 >> >> the 'classic' HTTP/1.0 handling -must- buffer the body if the connection >> will be renegotiated. This should no longer be handled inside the mod_ssl >> module itself, by itself. With the advent of filters, either apreq2 or >> another 'client buffer' module must be implemented. The logic looks like; >> >> client brigade read loop >> mem_body > max_memory_body ? >> create tmpfile if tmpfile isnull >> response 'failure' if total_body > max_buffer_body >> write body -> tmpfile >> reopen tmpfile read-only >> insert tmpfile bucket of tmpfile prior to remaining mem_body buckets. > >I'm not very familiar with the ssl-protocol upgrade stuff, so >I can't comment on the merits of what you're proposing. But I >can tell you that what you're suggesting here is pretty much >what mod_apreq already does.
Yup - I knew that ;-) >The basic idea is to represent >the spooled request data as a single brigade with a file bucket >on the end, together with some configuration settings that control >both brigade size and switchover behavior: from "append new buckets" >to "write new bucket data to file". Right. This lets us gather the entire client body into a normal stream. The advantage of migrating from a 'file bucket' over to a new 'temp file bucket' is that the temp file bucket logic could also destroy the tempfile on cleanup, trivially. It would really be not much more than a wrapper around the file bucket methods. >Factoring out that logic from >mod_apreq and importing it to httpd shouldn't be too hard. I think >it would be a bit more work to adjust mod_apreq to support this >behavior without a parser actually being present, but I'm sure we >could do it if there's a real desire for using apreq within httpd. 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. It still makes sense to de-chunk before writing this single temp file for a complete request body. Bill
