Joe Schaefer [EMAIL PROTECTED] writes:
[...]
Or they could all be required to punt on AP_MODE_GETLINE (like
mod_deflate does), which would mean some filters like mod_ext_filter
need a patch.
Here's the patch for mod_ext_filter (untested):
Index: modules/filters/mod_ext_filter.c
Joe Schaefer [EMAIL PROTECTED] writes:
Glenn Strauss [EMAIL PROTECTED] writes:
[...]
You suggested always using READBYTES. If a POST used chunked T-E to
send input, then when HTTP_IN is reading chunk trailers, too much data
might be read, i.e. the next request line might be read. What
Glenn Strauss [EMAIL PROTECTED] writes:
[...]
This just occurred to me: why not promote HTTP_IN to be a
connection level filter, and add a buffer brigade to http_ctx_t?
IIRC Bill Stoddard posted something like this about a year ago.
He and Brian Pane also discussed inverting the input
On Thu, Aug 12, 2004 at 02:06:39PM -0700, Justin Erenkrantz wrote:
--On Thursday, August 12, 2004 3:52 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
I saw so much repeated code for parsing brigades, that I created a
readahead API: ap_brigade_ra(). It is passed similar arguments as
those
On Thu, Aug 12, 2004 at 10:20:14AM -0700, Justin Erenkrantz wrote:
--On Thursday, August 12, 2004 2:51 AM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
of code duplication between modules. For example, the behavior of
line-mode is vauge and requires that callers re-parse the brigade
to
Justin Erenkrantz [EMAIL PROTECTED] writes:
[...]
Therefore, folding might only be possible to do in ap_http_filter, but
it can't go down further as into core_input_filter (which is where we
now call apr_brigade_split_line). A new getline_folding filter right
in front of ap_http_filter would
On Fri, Aug 13, 2004 at 12:37:30PM -0400, Joe Schaefer wrote:
Justin Erenkrantz [EMAIL PROTECTED] writes:
[...]
Therefore, folding might only be possible to do in ap_http_filter, but
it can't go down further as into core_input_filter (which is where we
now call apr_brigade_split_line).
Glenn Strauss [EMAIL PROTECTED] writes:
[...]
I really don't like the very confusing AP_MODE_* semantics
Would they be less confusing if the behavior was more consistent?
No, because of the burden these modes place other filters (eg
mod_deflate). Downstream input-filters /
On Fri, Aug 13, 2004 at 01:21:15PM -0400, Greg Ames wrote:
Glenn Strauss wrote:
On Wed, Aug 11, 2004 at 03:51:13PM -0700, Justin Erenkrantz wrote:
Please back up a bit.
Why do you think the modes should be combined? -- justin
More details:
-
Why bitflags, you ask?
On Fri, Aug 13, 2004 at 02:36:38PM -0400, Joe Schaefer wrote:
Glenn Strauss [EMAIL PROTECTED] writes:
If you are suggesting that there be no line-mode to read from filters,
I am.
then we might also need some sort of way to push excess data back up
the filter chain if we pulled it,
Glenn Strauss [EMAIL PROTECTED] writes:
[...]
I'm not sure the answer to this one:
Are protocol filters attached to the request (I think so)
or to the connection? If attached to the request, then
wouldn't they need to push-back excess data before the request
finishes if the data is to be
On Fri, Aug 13, 2004 at 03:08:17PM -0400, Joe Schaefer wrote:
Glenn Strauss [EMAIL PROTECTED] writes:
[...]
I'm not sure the answer to this one:
Are protocol filters attached to the request (I think so)
or to the connection? If attached to the request, then
wouldn't they need to
Glenn Strauss [EMAIL PROTECTED] writes:
On Fri, Aug 13, 2004 at 03:08:17PM -0400, Joe Schaefer wrote:
Glenn Strauss [EMAIL PROTECTED] writes:
[...]
I'm not sure the answer to this one:
Are protocol filters attached to the request (I think so)
or to the connection? If attached
On Wed, Aug 11, 2004 at 03:51:13PM -0700, Justin Erenkrantz wrote:
--On Wednesday, August 11, 2004 5:16 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
I'm finding ap_input_mode_t very restrictive as a linear enum
and would like to make it an enum of bitflags.
Please back up a bit.
--On Thursday, August 12, 2004 2:51 AM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
/** The filter should pass any special buckets (not in-memory) as long
as it * does not need to perform any processing on them (translation
or protocol * delimiting) (augments AP_MODE_BYTES;
I think your response demonstrates fairly well how obtuse input
filtering has become. ;)
I saw so much repeated code for parsing brigades, that I created a
readahead API: ap_brigade_ra(). It is passed similar arguments as
those to input filters, and additionally is passed a readahead struct
and
--On Thursday, August 12, 2004 3:52 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
I saw so much repeated code for parsing brigades, that I created a
readahead API: ap_brigade_ra(). It is passed similar arguments as
those to input filters, and additionally is passed a readahead struct
and a
Glenn Strauss [EMAIL PROTECTED] writes:
I think your response demonstrates fairly well how obtuse input
filtering has become. ;)
IMO ap_input_mode_t should disappear and APR_NONBLOCK_READ
should either be fixed or dumped as well. For a filter
invoked with APR_BLOCK_READ, there's nothing in
I'm finding ap_input_mode_t very restrictive as a linear enum
and would like to make it an enum of bitflags.
If I put together a patch, what are the chances it will be accepted?
It is for Apache 2.1/2.2 only, because it
a) breaks binary compatibility by changing the ap_input_mode_t values
b)
--On Wednesday, August 11, 2004 5:16 PM -0400 Glenn Strauss
[EMAIL PROTECTED] wrote:
I'm finding ap_input_mode_t very restrictive as a linear enum
and would like to make it an enum of bitflags.
Please back up a bit.
Why do you think the modes should be combined? -- justin
20 matches
Mail list logo
