httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Fri, 03 Nov 2000 19:45:26 GMT
Sascha Schumann <> writes:

> > I think the fix is to leave content length filter in there, but if it
> > sees a flush bucket prior to EOS it should disable itself and let
> > everything flow as it comes.
> >
> > A module has to do a flush to let the content flow to the client ASAP
> > so we can use that trigger to know what to do.
> >
> > Does that sound reasonable?
>     It does, but I'm not sure that adding the overhead of
>     examining each bucket is the best option.

I feel your pain...

>     We have no_cache and no_local_copy in the request structure.
>     How about no_content_length?

Another idea: require a flush bucket, if any, to be the last bucket in
a brigade (often it will be the only bucket)... this would eliminate the
need to walk through the brigade...

I'm not sure which I dislike the least:

. another flag
. the requirement that a flush bucket can appear only at the end
. walking through the entire brigade

I'm leaning towards the requirement that the flush bucket can appear
only at the end...  This would *seem* to be a very natural requirement.
Currently, not all filters have logic to process the flush bucket
specially, but any such filter is liable to break streaming output so
I guess they'll get fixed PDQ anyway.

This issue isn't unique to content-length calculation. Consider
calculating the md5.  As with content length, it is easy to handle
this in a filter.  This too needs to cease and desist for streaming
output.  I guess it can look at a no_content_length flag or such a
flag can be renamed to streaming or some such.


Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message