You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by tr...@apache.org on 2001/02/05 16:04:32 UTC
cvs commit: httpd-2.0/modules/proxy proxy_http.c
trawick 01/02/05 07:04:32
Modified: . CHANGES
server/mpm/beos beos.c
server/mpm/dexter dexter.c
server/mpm/mpmt_beos mpmt_beos.c
server/mpm/mpmt_pthread mpmt_pthread.c
server/mpm/perchild perchild.c
server/mpm/spmt_os2 spmt_os2.c
include http_connection.h
modules/proxy proxy_http.c
Log:
ap_new_connection() returns NULL if an error occurred (prefork MPM
and ap_new_connection() were changed last week)
I have skipped putting the change into WinNT MPM and mod_proxy. I
left a note in the mod_proxy code; for the NT MPM I think I can talk
somebody into doing the right thing for me.
Revision Changes Path
1.74 +4 -0 httpd-2.0/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/httpd-2.0/CHANGES,v
retrieving revision 1.73
retrieving revision 1.74
diff -u -r1.73 -r1.74
--- CHANGES 2001/02/05 01:02:26 1.73
+++ CHANGES 2001/02/05 15:04:30 1.74
@@ -1,5 +1,9 @@
Changes with Apache 2.0b1
+ *) ap_new_connection() closes the socket and returns NULL if a socket
+ call fails. Usually this is due to a connection which has been
+ reset. [Jeff Trawick]
+
*) Move the Apache version information out of httpd.h and into release.h.
This is in preparation for the first tag with the new tag and release
system. [Ryan Bloom]
1.35 +4 -3 httpd-2.0/server/mpm/beos/beos.c
Index: beos.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/beos/beos.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- beos.c 2001/02/04 03:12:48 1.34
+++ beos.c 2001/02/05 15:04:31 1.35
@@ -317,9 +317,10 @@
}
current_conn = ap_new_connection(p, ap_server_conf, sock, conn_id);
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
static int32 worker_thread(void * dummy)
1.141 +4 -3 httpd-2.0/server/mpm/dexter/dexter.c
Index: dexter.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/dexter/dexter.c,v
retrieving revision 1.140
retrieving revision 1.141
diff -u -r1.140 -r1.141
--- dexter.c 2001/02/01 21:54:37 1.140
+++ dexter.c 2001/02/05 15:04:31 1.141
@@ -419,9 +419,10 @@
SERVER_BUSY_READ, (request_rec *) NULL);
current_conn = ap_new_connection(p, ap_server_conf, sock, conn_id);
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
static void *worker_thread(void *);
1.61 +4 -3 httpd-2.0/server/mpm/mpmt_beos/mpmt_beos.c
Index: mpmt_beos.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/mpmt_beos/mpmt_beos.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- mpmt_beos.c 2001/02/04 03:12:48 1.60
+++ mpmt_beos.c 2001/02/05 15:04:31 1.61
@@ -300,9 +300,10 @@
int csd;
current_conn = ap_new_connection(p, ap_server_conf, sock, conn_id);
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
static int32 worker_thread(void * dummy)
1.138 +4 -3 httpd-2.0/server/mpm/mpmt_pthread/mpmt_pthread.c
Index: mpmt_pthread.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/mpmt_pthread/mpmt_pthread.c,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- mpmt_pthread.c 2001/02/04 03:12:48 1.137
+++ mpmt_pthread.c 2001/02/05 15:04:31 1.138
@@ -410,9 +410,10 @@
SERVER_BUSY_READ, (request_rec *) NULL);
current_conn = ap_new_connection(p, ap_server_conf, sock, conn_id);
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
/* Sets workers_may_exit if we received a character on the pipe_of_death */
static void check_pipe_of_death(void)
1.37 +4 -3 httpd-2.0/server/mpm/perchild/perchild.c
Index: perchild.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/perchild/perchild.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- perchild.c 2001/01/20 21:42:21 1.36
+++ perchild.c 2001/02/05 15:04:32 1.37
@@ -456,9 +456,10 @@
}
current_conn = ap_new_connection(p, ap_server_conf, sock, conn_id);
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
static void *worker_thread(void *);
1.75 +4 -3 httpd-2.0/server/mpm/spmt_os2/spmt_os2.c
Index: spmt_os2.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/spmt_os2/spmt_os2.c,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -r1.74 -r1.75
--- spmt_os2.c 2001/02/04 03:12:49 1.74
+++ spmt_os2.c 2001/02/05 15:04:32 1.75
@@ -940,9 +940,10 @@
current_conn = ap_new_connection(ptrans, ap_server_conf, csd,
THREAD_GLOBAL(child_num));
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
clean_child_exit(0);
1.33 +1 -0 httpd-2.0/include/http_connection.h
Index: http_connection.h
===================================================================
RCS file: /home/cvs/httpd-2.0/include/http_connection.h,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- http_connection.h 2001/02/04 03:00:14 1.32
+++ http_connection.h 2001/02/05 15:04:32 1.33
@@ -73,6 +73,7 @@
* @param server The server to create the connection for
* @param inout The socket to use for all communication with the client
* @param id ID of this connection; unique at any point in time.
+ * @return new conn_rec, or NULL if the connection has already been reset
*/
conn_rec *ap_new_connection(apr_pool_t *p, server_rec *server,
apr_socket_t *inout, long id);
1.28 +6 -0 httpd-2.0/modules/proxy/proxy_http.c
Index: proxy_http.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- proxy_http.c 2001/01/19 07:04:25 1.27
+++ proxy_http.c 2001/02/05 15:04:32 1.28
@@ -277,6 +277,12 @@
}
origin = ap_new_connection(r->pool, r->server, sock, 0);
+ if (!origin) {
+ /* the peer reset the connection already; ap_new_connection()
+ * closed the socket */
+ /* XXX somebody that knows what they're doing add an error path */
+ }
+
ap_add_output_filter("CORE", NULL, NULL, origin);
clear_connection(r->pool, r->headers_in); /* Strip connection-based headers */
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: <rb...@covalent.net>
Sent: Monday, February 05, 2001 9:57 AM
>
> I never thought I would suggest this. I think we should remove the proxy
> from the tree. I am subscribed to the proxy mailing list, and it is dead
> and has been for a very long time. The code doesn't compile, and nobody
> seems all that interested in making it compile. Unless we are actually
> going to develop that code, I do not believe it belongs in the tree.
>
> I would suggest the following setup.
>
> Let's create a separate cvs tree for mod_proxy on apache.org. If it
> continues to be dead, then we can ignore it. If it starts to pick up
> speed, then at some point we could merge it back into the httpd-2.0 tree.
httpd-proxy-2.0?
+1
This is a substantial entity into and of itself. There are a number of ASF
projects that are fully integrated into httpd-2.0, but don't reside in the
primary tree. Take modperl-2.0 for example.
You could argue RFC2616 is the httpd-2.0 subset. I don't.
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by Ben Hyde <bh...@pobox.com>.
Greg Stein <gs...@lyra.org> writes:
> What is the difference between shipping a broken / poor proxy in the beta,
> and separately shipping it [from a different CVS module] ?
In the tarball seems more accessible than a communityless CVS module;
but I really don't have strong intuitions which is more likely to get
the desired effect: interested hands on busy in the code.
So: you've convinced me.
It is clearly a drag, as are some other modules.
It also creates a chance for people to have some fun trying
some tricks in and around area of proxy functionality.
Thanks for listening.
- ben
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 07, 2001 at 02:32:54PM -0500, Ben Hyde wrote:
>...
> I think we'd all agree that the choice is about what triggers greatest
> chance of development happening is a good thing to focus on.
Agreed here :-)
> If it's
> the barrier of not having a more open CVS repository for it then
> certainly we should fix that - but I suspect it's more a matter of not
> having a sufficent need. Shipping it with the beta, along with an
> invitation to help get it working, will put it in reach of a lot more
> people. I'm reasonably certain that some of those people we desperately
> desire a working version and that will be sufficent to thing rolling
> again.
What is the difference between shipping a broken / poor proxy in the beta,
and separately shipping it [from a different CVS module] ? To some extent,
the latter is even more of a motivator: if the functionality just isn't
there by default, then those that desire it will get crackin'.
Our problem is getting enough people to actually work on the codebase for a
significant and prolonged period. No matter how to want to slice it or
explain it, it all boils down to a lack of volunteers right now.
When those volunteers arrive, for whatever reason, they will be able to work
on it anywhere it lives. And if that is the case, then can somebody provide
a good reason for why it must remain in the core? (where it just bogs us
down, per my "history" email)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 07, 2001 at 02:32:54PM -0500, Ben Hyde wrote:
>...
> I think we'd all agree that the choice is about what triggers greatest
> chance of development happening is a good thing to focus on.
Agreed here :-)
> If it's
> the barrier of not having a more open CVS repository for it then
> certainly we should fix that - but I suspect it's more a matter of not
> having a sufficent need. Shipping it with the beta, along with an
> invitation to help get it working, will put it in reach of a lot more
> people. I'm reasonably certain that some of those people we desperately
> desire a working version and that will be sufficent to thing rolling
> again.
What is the difference between shipping a broken / poor proxy in the beta,
and separately shipping it [from a different CVS module] ? To some extent,
the latter is even more of a motivator: if the functionality just isn't
there by default, then those that desire it will get crackin'.
Our problem is getting enough people to actually work on the codebase for a
significant and prolonged period. No matter how to want to slice it or
explain it, it all boils down to a lack of volunteers right now.
When those volunteers arrive, for whatever reason, they will be able to work
on it anywhere it lives. And if that is the case, then can somebody provide
a good reason for why it must remain in the core? (where it just bogs us
down, per my "history" email)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by Ben Hyde <bh...@pobox.com>.
rbb@covalent.net writes:
> > > > I never thought I would suggest this. I think we should remove the proxy
> > > > from the tree
> > >
> > > I have mixed thoughts on this one.. On one hand, I agree with your pragmatic
> > > approach, on the other, we -must- have proxy pass function in the server to
> > > allow transparently "redirecting" (not HTTP redirect) traffic to back-end
> > > servers based on URL. My $.02
> >
> > I don't see why the first beta can't ship with modules labeled as - alpha
> > or pre-alpha. I suspect we will get more hands on deck once the beta
> > ships. A lot of sites use both proxy and rewrite. - ben
>
> ... My problem with the proxy, is that the
> development isn't happening at all.
I think we'd all agree that the choice is about what triggers greatest
chance of development happening is a good thing to focus on. If it's
the barrier of not having a more open CVS repository for it then
certainly we should fix that - but I suspect it's more a matter of not
having a sufficent need. Shipping it with the beta, along with an
invitation to help get it working, will put it in reach of a lot more
people. I'm reasonably certain that some of those people we desperately
desire a working version and that will be sufficent to thing rolling
again.
- ben
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by rb...@covalent.net.
> > > I never thought I would suggest this. I think we should remove the proxy
> > > from the tree
> >
> > I have mixed thoughts on this one.. On one hand, I agree with your pragmatic
> > approach, on the other, we -must- have proxy pass function in the server to
> > allow transparently "redirecting" (not HTTP redirect) traffic to back-end
> > servers based on URL. My $.02
>
> I don't see why the first beta can't ship with modules labeled as - alpha
> or pre-alpha. I suspect we will get more hands on deck once the beta
> ships. A lot of sites use both proxy and rewrite. - ben
We shipped a8 with a pre-alpha version of the proxy, and it worked,
although it didn't do any caching. When we moved the tree to httpd-2.0,
we horribly broke the proxy, and it hasn't been touched since (except for
Chuck's fix earlier today). My problem with the proxy, is that the
development isn't happening at all. At least mod_rewrite continues to
compile and pass minimal tests. Mod_proxy doesn't even meet those
criteria.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by Ben Hyde <bh...@pobox.com>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> >
> > I never thought I would suggest this. I think we should remove the proxy
> > from the tree
>
> I have mixed thoughts on this one.. On one hand, I agree with your pragmatic
> approach, on the other, we -must- have proxy pass function in the server to
> allow transparently "redirecting" (not HTTP redirect) traffic to back-end
> servers based on URL. My $.02
I don't see why the first beta can't ship with modules labeled as - alpha
or pre-alpha. I suspect we will get more hands on deck once the beta
ships. A lot of sites use both proxy and rewrite. - ben
punt the proxy (was: Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 05, 2001 at 10:13:41AM -0800, rbb@covalent.net wrote:
> > > I never thought I would suggest this. I think we should remove the proxy
> > > from the tree
Heh. You Covalent guys... I was just talking to Randy about this a bit over
a week ago. I said the same thing: "nobody is working on the proxy code, yet
every time we say 'rip it out' somebody comes along and says they'll work on
it; two weeks later it is dead again."
Personally, I think I started pushing to rip out the proxy at least a year
ago. And my mind hasn't changed one bit. It really should go. This stupid
bit about "oh, but I'll work on it" every time this discussion comes up is
just insane. I think we've done this twice now. Each time, somebody says
they'll work on it, but *zero* happens. Screw it. They can work on it in a
separate CVS tree. (as a sub-project of the httpd PMC)
> > I have mixed thoughts on this one.. On one hand, I agree with your pragmatic
> > approach, on the other, we -must- have proxy pass function in the server to
> > allow transparently "redirecting" (not HTTP redirect) traffic to back-end
> > servers based on URL. My $.02
Let's be clear: you're asking for a *reverse* proxy here. That is a simpler
beast than a general proxy, thankfully. I believe a full forward proxy is
just dumb within Apache -- send people over to squid if they want that.
Personally, I would punt the entire proxy bundle to another CVS tree. When
somebody comes back with reverse proxy code, then we can put that portion
back into the tree.
> I agree completely. I just dislike all the dead code in the tree. I kind
> of would rather put a VERY light-weight proxy in the code, that just does
> the bare minimum, until we get a real proxy done.
Punt it all. When it is in shape, then it can come back.
I think back to when I asked about whether mod_dav could go into Apache. The
answer was always conditioned on having an active maintainer for the code.
The proxy stuff doesn't satisfy that, and it shouldn't return until that can
happen. IMO, it really should go.
If we get a teeny, simple, reverse proxy module, then the group as a whole
may be able to maintain it. But anything bigger needs a real maintainer.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by rb...@covalent.net.
> > I never thought I would suggest this. I think we should remove the proxy
> > from the tree
>
> I have mixed thoughts on this one.. On one hand, I agree with your pragmatic
> approach, on the other, we -must- have proxy pass function in the server to
> allow transparently "redirecting" (not HTTP redirect) traffic to back-end
> servers based on URL. My $.02
I agree completely. I just dislike all the dead code in the tree. I kind
of would rather put a VERY light-weight proxy in the code, that just does
the bare minimum, until we get a real proxy done.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> I never thought I would suggest this. I think we should remove the proxy
> from the tree
I have mixed thoughts on this one.. On one hand, I agree with your pragmatic
approach, on the other, we -must- have proxy pass function in the server to
allow transparently "redirecting" (not HTTP redirect) traffic to back-end
servers based on URL. My $.02
Bill
Re: cvs commit: httpd-2.0/modules/proxy proxy_http.c
Posted by rb...@covalent.net.
> Modified: . CHANGES
> server/mpm/beos beos.c
> server/mpm/dexter dexter.c
> server/mpm/mpmt_beos mpmt_beos.c
> server/mpm/mpmt_pthread mpmt_pthread.c
> server/mpm/perchild perchild.c
> server/mpm/spmt_os2 spmt_os2.c
> include http_connection.h
> modules/proxy proxy_http.c
> Log:
> ap_new_connection() returns NULL if an error occurred (prefork MPM
> and ap_new_connection() were changed last week)
>
> I have skipped putting the change into WinNT MPM and mod_proxy. I
> left a note in the mod_proxy code; for the NT MPM I think I can talk
> somebody into doing the right thing for me.
I never thought I would suggest this. I think we should remove the proxy
from the tree. I am subscribed to the proxy mailing list, and it is dead
and has been for a very long time. The code doesn't compile, and nobody
seems all that interested in making it compile. Unless we are actually
going to develop that code, I do not believe it belongs in the tree.
I would suggest the following setup.
Let's create a separate cvs tree for mod_proxy on apache.org. If it
continues to be dead, then we can ignore it. If it starts to pick up
speed, then at some point we could merge it back into the httpd-2.0 tree.
Thoughts?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------