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 16:42:04 GMT
At 10:15 AM 12/29/2004, Joe Schaefer wrote:
>"William A. Rowe, Jr." <> 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.


View raw message