"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. 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". 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. -- Joe Schaefer
