I started out trying to get flood to support chunked encoding (as
recent changes to httpd have started to let chunked encoding work).
Then, I decided to look at how httpd-2.0 handles dechunking (as it
needs to be able to handle chunked input).
The current dechunk code can't handle trailers prope
Hi Justin.
A good place to test the de-chunk logic is via the proxy module.
via the proxy, go to sites like apple.com/macosx
and see if the dechunking breaks them.
Regards
Ian
Justin Erenkrantz wrote:
> I started out trying to get flood to support chunked encoding (as
> recent changes to httpd
None of this can be committed until it has passed all of the tests in the perl test
framework. The last time somebody (me) mucked with these filters it broke all of the
CGI script handling. I would also like to hear from Jeff about this, because when we
wrote the filters originally, we had input
On Sun, Sep 23, 2001 at 08:33:07AM -0700, Ryan Bloom wrote:
>
> None of this can be committed until it has passed all of the tests in the perl test
> framework. The last time somebody (me) mucked with these filters it broke all of the
> CGI script handling. I would also like to hear from Jeff abo
On Sun, 23 Sep 2001, Justin Erenkrantz wrote:
> > You can't do this. The reason for the immortal bucket, was that we
> > are closing the pipe or socket bucket. What this change does, is it
> > closes the pipe, but leaves the bucket in the brigade. This will
> > cause problems later. You can't
On Sunday 23 September 2001 11:28 am, Cliff Woolley wrote:
> On Sun, 23 Sep 2001, Justin Erenkrantz wrote:
> > > You can't do this. The reason for the immortal bucket, was that we
> > > are closing the pipe or socket bucket. What this change does, is it
> > > closes the pipe, but leaves the buck
On Sunday 23 September 2001 09:48 am, Justin Erenkrantz wrote:
> > > Index: buckets/apr_brigade.c
> > > ===
> > > RCS file: /home/cvs/apr-util/buckets/apr_brigade.c,v
> > > retrieving revision 1.25
> > > diff -u -r1.25 apr_brigade.c
>
On Sun, Sep 23, 2001 at 08:33:07AM -0700, Ryan Bloom wrote:
>
> None of this can be committed until it has passed all of the tests in the perl test
> framework. The last time somebody (me) mucked with these filters it broke all of the
> CGI script handling. I would also like to hear from Jeff abo
On Sun, Sep 23, 2001 at 02:53:14PM -0700, Greg Stein wrote:
> Euh... not sure if you typoed. Input filters should *NOT* return more than
> they were asked for. Never.
Yup. That's currently what can happen.
> >...
> > > --- include/apr_buckets.h 2001/09/22 22:36:07 1.118
> > > +++ include/ap
On Sun, Sep 23, 2001 at 03:04:54PM -0700, Ryan Bloom wrote:
> That would be true if this function were to go into httpd, but it isn't. It is
> going into APR-util, and there is nothing saying that you will have a
> brigade of a defined size.
The doc for my proposed function (ap_brigade_to_buffer
On Sun, Sep 23, 2001 at 03:21:38PM -0700, Ryan Bloom wrote:
> What we are doing now, is forcing our clean bucket API into an API designed
> around the BUFF logic.
Which is exactly what ap_get_client_block does and where this function
is used. =-)
If we'd like to deprecate ap_get_client_block...
On Sunday 23 September 2001 02:53 pm, Greg Stein wrote:
> On Sun, Sep 23, 2001 at 08:33:07AM -0700, Ryan Bloom wrote:
> > None of this can be committed until it has passed all of the tests in the
> > perl test framework. The last time somebody (me) mucked with these
> > filters it broke all of the
On Sunday 23 September 2001 03:28 pm, Justin Erenkrantz wrote:
> On Sun, Sep 23, 2001 at 03:21:38PM -0700, Ryan Bloom wrote:
> > What we are doing now, is forcing our clean bucket API into an API
> > designed around the BUFF logic.
>
> Which is exactly what ap_get_client_block does and where this
On Sunday 23 September 2001 03:12 pm, Justin Erenkrantz wrote:
> On Sun, Sep 23, 2001 at 03:04:54PM -0700, Ryan Bloom wrote:
> > That would be true if this function were to go into httpd, but it isn't.
> > It is going into APR-util, and there is nothing saying that you will have
> > a brigade of
Take two.
As Greg suggested, this merges the dechunk and core filters back
to one filter. (This makes the diff in http_protocol.c a bit
gnarly.)
Other significant changes is that the HTTP_IN (ap_http_filter) is
now a request-level filter rather than a connection-level filter.
This makes a lot m
On Sun, 23 Sep 2001, Greg Stein wrote:
> > > +APU_DECLARE(apr_status_t) apr_brigade_to_buffer(apr_bucket_brigade *b,
> > > char *c); +
>
> Ryan said this should take a reading mode. I don't understand why that
> should be necessary. You have a brigade of a defined size, and you're
> flattening th
On Sunday 23 September 2001 06:58 pm, Justin Erenkrantz wrote:
> Take two.
>
> As Greg suggested, this merges the dechunk and core filters back
> to one filter. (This makes the diff in http_protocol.c a bit
> gnarly.)
>
> Other significant changes is that the HTTP_IN (ap_http_filter) is
> now a r
On Sunday 23 September 2001 08:35 pm, Cliff Woolley wrote:
> On Sun, 23 Sep 2001, Greg Stein wrote:
> > > > +APU_DECLARE(apr_status_t) apr_brigade_to_buffer(apr_bucket_brigade
> > > > *b, char *c); +
> >
> > Ryan said this should take a reading mode. I don't understand why that
> > should be neces
On Sun, 23 Sep 2001, Justin Erenkrantz wrote:
> Index: buckets/apr_buckets_pipe.c
> ===
> RCS file: /home/cvs/apr-util/buckets/apr_buckets_pipe.c,v
> retrieving revision 1.41
> diff -u -r1.41 apr_buckets_pipe.c
> --- buckets/apr_buck
On Sun, Sep 23, 2001 at 08:34:00PM -0700, Ryan Bloom wrote:
> On Sunday 23 September 2001 06:58 pm, Justin Erenkrantz wrote:
>...
> > Other significant changes is that the HTTP_IN (ap_http_filter) is
> > now a request-level filter rather than a connection-level filter.
> > This makes a lot more se
On Sun, Sep 23, 2001 at 08:34:00PM -0700, Ryan Bloom wrote:
> I don't see how this works at all for pipelined requests. You moved the HTTP_IN
> filter from a connection filter to a request filter. But, the only connection filter
>we
> have is the CORE_iN filter. All that filter does, is to pass
On Sunday 23 September 2001 09:21 pm, Greg Stein wrote:
> > I don't see how this works at all for pipelined requests. You moved the
> > HTTP_IN filter from a connection filter to a request filter. But, the
> > only connection filter we have is the CORE_iN filter. All that filter
> > does, is to
On Sun, Sep 23, 2001 at 03:04:54PM -0700, Ryan Bloom wrote:
> On Sunday 23 September 2001 02:53 pm, Greg Stein wrote:
> > On Sun, Sep 23, 2001 at 08:33:07AM -0700, Ryan Bloom wrote:
> > > None of this can be committed until it has passed all of the tests in the
> > > perl test framework. The last
On Sunday 23 September 2001 09:22 pm, Justin Erenkrantz wrote:
> On Sun, Sep 23, 2001 at 08:34:00PM -0700, Ryan Bloom wrote:
> > I don't see how this works at all for pipelined requests. You moved the
> > HTTP_IN filter from a connection filter to a request filter. But, the
> > only connection fi
On Sun, 23 Sep 2001, Ryan Bloom wrote:
> I don't see this at all. It is not possible to specify how much is
> read from the socket itself. I just read through the bucket_socket
> code, and we always try to read APR_BUCKET_BUFF_SIZE. This seems to
> mean that we are going to read more from the
On Wed, Sep 19, 2001 at 02:40:38AM -0700, Greg Stein wrote:
> Understood. I meant "there is more cleanup that can be done."
The following patch cleans up the fdqueue a bit more. It implements Greg's
suggestions above (getting rid of redundant variables, etc), as well as
converting the simple ap_
In a message dated 01-09-24 00:37:41 EDT, Justin wrote...
> > The only real question is what happens when readbytes is -1 - a
> > higher-level filter explicitly asks for everything. We'd then do a
> > blocking read for the entire socket until it is exhausted. I think
> > the current code wo
27 matches
Mail list logo
