You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2002/03/03 23:04:28 UTC
RE: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
> Subject: cvs commit: httpd-2.0/server protocol.c request.c
util_filter.c
>
> rbb 02/03/03 14:04:04
>
> Modified: server protocol.c request.c util_filter.c
> Log:
> This fixes most of the header bug that was committed last night.
The
> server
> is seg faulting on pipelined requests currently, but I want to get
> people
> back to a running server.
This patch is kind of ugly, but it cleans the code up a bit. The seg
fault that we are still seeing is not in this code, but it looks like
r->connection->input_filters is being clobbered by some of the core
logic. I am still tracking that down.
Ryan
RE: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
Posted by Ryan Bloom <rb...@covalent.net>.
I have reproduced both bugs. I think I have a solution for the first.
I haven't looked at the second yet.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: Sunday, March 03, 2002 9:00 PM
> To: dev@httpd.apache.org
> Subject: RE: cvs commit: httpd-2.0/server protocol.c request.c
> util_filter.c
>
> I'm checking on this again, but I definitely made the first request in
> your message. Did you do a make clean before you built?
>
> Ryan
>
> ----------------------------------------------
> Ryan Bloom rbb@covalent.net
> 645 Howard St. rbb@apache.org
> San Francisco, CA
>
> > -----Original Message-----
> > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > Sent: Sunday, March 03, 2002 8:51 PM
> > To: dev@httpd.apache.org; rbb@covalent.net
> > Subject: Re: cvs commit: httpd-2.0/server protocol.c request.c
> > util_filter.c
> >
> > On Sun, Mar 03, 2002 at 02:34:39PM -0800, Ryan Bloom wrote:
> > > Anyway, the seg fault is gone, and the headers are behaving
> correctly in
> > > all of my tests.
> >
> > With the default httpd-std.conf:
> >
> > GET / HTTP/1.1
> > Host: foo
> >
> > causes an infinite loop at util_filter.c:347. Looks like the
request
> > chain gets corrupted such that first == first->next.
> >
> > GET /manual/ HTTP/1.1
> > Host: foo
> >
> > causes no headers to be returned.
> >
> > I'll try to take a look at this later tonight, but no promises on my
> > part. I understand that you are trying your best to get this to
> > work, and I appreciate that. =) -- justin
>
RE: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
Posted by Ryan Bloom <rb...@covalent.net>.
Well, the fix for the first has been committed. The fix for the second
is making me re-read some amazing code. I just found out that we have
two functions in the http module that insert required filters. Both are
called whenever we have an error condition.
Think about that. I have just traced a request that had three instances
of HTTP_HEADER and CONTENT_LENGTH inserted.
Fix coming very soon now.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: Sunday, March 03, 2002 9:00 PM
> To: dev@httpd.apache.org
> Subject: RE: cvs commit: httpd-2.0/server protocol.c request.c
> util_filter.c
>
> I'm checking on this again, but I definitely made the first request in
> your message. Did you do a make clean before you built?
>
> Ryan
>
> ----------------------------------------------
> Ryan Bloom rbb@covalent.net
> 645 Howard St. rbb@apache.org
> San Francisco, CA
>
> > -----Original Message-----
> > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > Sent: Sunday, March 03, 2002 8:51 PM
> > To: dev@httpd.apache.org; rbb@covalent.net
> > Subject: Re: cvs commit: httpd-2.0/server protocol.c request.c
> > util_filter.c
> >
> > On Sun, Mar 03, 2002 at 02:34:39PM -0800, Ryan Bloom wrote:
> > > Anyway, the seg fault is gone, and the headers are behaving
> correctly in
> > > all of my tests.
> >
> > With the default httpd-std.conf:
> >
> > GET / HTTP/1.1
> > Host: foo
> >
> > causes an infinite loop at util_filter.c:347. Looks like the
request
> > chain gets corrupted such that first == first->next.
> >
> > GET /manual/ HTTP/1.1
> > Host: foo
> >
> > causes no headers to be returned.
> >
> > I'll try to take a look at this later tonight, but no promises on my
> > part. I understand that you are trying your best to get this to
> > work, and I appreciate that. =) -- justin
>
RE: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
Posted by Ryan Bloom <rb...@covalent.net>.
I'm checking on this again, but I definitely made the first request in
your message. Did you do a make clean before you built?
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: Sunday, March 03, 2002 8:51 PM
> To: dev@httpd.apache.org; rbb@covalent.net
> Subject: Re: cvs commit: httpd-2.0/server protocol.c request.c
> util_filter.c
>
> On Sun, Mar 03, 2002 at 02:34:39PM -0800, Ryan Bloom wrote:
> > Anyway, the seg fault is gone, and the headers are behaving
correctly in
> > all of my tests.
>
> With the default httpd-std.conf:
>
> GET / HTTP/1.1
> Host: foo
>
> causes an infinite loop at util_filter.c:347. Looks like the request
> chain gets corrupted such that first == first->next.
>
> GET /manual/ HTTP/1.1
> Host: foo
>
> causes no headers to be returned.
>
> I'll try to take a look at this later tonight, but no promises on my
> part. I understand that you are trying your best to get this to
> work, and I appreciate that. =) -- justin
Re: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, Mar 03, 2002 at 02:34:39PM -0800, Ryan Bloom wrote:
> Anyway, the seg fault is gone, and the headers are behaving correctly in
> all of my tests.
With the default httpd-std.conf:
GET / HTTP/1.1
Host: foo
causes an infinite loop at util_filter.c:347. Looks like the request
chain gets corrupted such that first == first->next.
GET /manual/ HTTP/1.1
Host: foo
causes no headers to be returned.
I'll try to take a look at this later tonight, but no promises on my
part. I understand that you are trying your best to get this to
work, and I appreciate that. =) -- justin
RE: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
Posted by Ryan Bloom <rb...@covalent.net>.
> > Subject: cvs commit: httpd-2.0/server protocol.c request.c
> util_filter.c
> >
> > rbb 02/03/03 14:04:04
> >
> > Modified: server protocol.c request.c util_filter.c
> > Log:
> > This fixes most of the header bug that was committed last night.
> The
> > server
> > is seg faulting on pipelined requests currently, but I want to get
> > people
> > back to a running server.
>
> This patch is kind of ugly, but it cleans the code up a bit. The seg
> fault that we are still seeing is not in this code, but it looks like
> r->connection->input_filters is being clobbered by some of the core
> logic. I am still tracking that down.
I have found and fixed the seg fault. The problem was that some of the
input filters had the wrong filter types. They were being registered as
CONNECTION or CONTENT filters, but they were being treated as
HTTP_HEADER filters.
This meant that there were filters in the list that were associated with
previous requests. Obviously, this meant that the memory allocation was
completely borked. In this specific case, the
r->connection->input_filters was being overwritten by
apr_filepath_merge. I had originally assumed that the problem was in
apr_filepath_merge (because my code couldn't be wrong. :-), but in
reality the problem was that the problem was an extra filter in the
list.
Anyway, the seg fault is gone, and the headers are behaving correctly in
all of my tests.
Ryan
RE: cvs commit: httpd-2.0/server protocol.c request.c util_filter.c
Posted by Ryan Bloom <rb...@covalent.net>.
> > Subject: cvs commit: httpd-2.0/server protocol.c request.c
> util_filter.c
> >
> > rbb 02/03/03 14:04:04
> >
> > Modified: server protocol.c request.c util_filter.c
> > Log:
> > This fixes most of the header bug that was committed last night.
> The
> > server
> > is seg faulting on pipelined requests currently, but I want to get
> > people
> > back to a running server.
>
> This patch is kind of ugly, but it cleans the code up a bit. The seg
> fault that we are still seeing is not in this code, but it looks like
> r->connection->input_filters is being clobbered by some of the core
> logic. I am still tracking that down.
I have found and fixed the seg fault. The problem was that some of the
input filters had the wrong filter types. They were being registered as
CONNECTION or CONTENT filters, but they were being treated as
HTTP_HEADER filters.
This meant that there were filters in the list that were associated with
previous requests. Obviously, this meant that the memory allocation was
completely borked. In this specific case, the
r->connection->input_filters was being overwritten by
apr_filepath_merge. I had originally assumed that the problem was in
apr_filepath_merge (because my code couldn't be wrong. :-), but in
reality the problem was that the problem was an extra filter in the
list.
Anyway, the seg fault is gone, and the headers are behaving correctly in
all of my tests.
Ryan