You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Williams <dw...@cisco.com> on 2001/02/02 07:10:56 UTC
RE: beta?
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> > > > James Sutherland wrote:
> > > > [snip]
> > > > >
> > > > > The question is, what "protocol" to use? Just sending a
> > > struct describing
> > > > > what's going on is one option; have each process send to a socket
> > > > > (UDP??) with the monitoring module/process running on?
> > > >
> > > > This is solution that works.
> > > >
> > > > However, I also miss still a protocol field in the
> > > > server_rec. If Apache can support multiple protocol
> > > > via protocol modules it is my opinion that each
> > > > server ('server_rec') needs to know which protocol
> > > > it serves.
> >
> > Seems that each server does need to know which protocol it is capable of
> > serving. And in cases where it supports multiple ones, use the
> > request_rec->protocol field to determine how to handle that particular
> > request.
>
> Now you've lost me ... a "server" in this context is a binding of an IP
> address and port - it inherently "knows" what it should do through the
> configuration (which is derived from that binding).
I am under the impression that ap_hook_process_connection() was provided to
allow non-http protocol modules to hook into the processing path? So that a
given server process (e.g. child_main() in prefork.c) could handle multiple
protocols, which could all be sent to the same port if desired.
>
> >
> > > ?? So how come mod_echo works without one of these?
> >
> > mod_echo might not be the best example, since it doesn't care about the
> > protocol at all, simply echoing what was received.
>
> Errr ... and how is this not a protocol? Wouldn't you be a little upset
> if your webserver thought that's what it should do?
I meant mod_echo is not a protocol in the sense that it cares about request.
It would treat
GET http://www.foo.org HTTP/1.1
METHOD_X New_Transport_Protocol:Resource_locator NTP/1.0
the same and hijack the incoming request. Where as a more protocol aware
module would examine the PDU and decline the request if it doesn't
understand it. Giving ap_process_http_connection() or other protocol
modules a chance to handle it.
-david
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
> > > So that a
> > > given server process (e.g. child_main() in prefork.c) could handle multiple
> > > protocols, which could all be sent to the same port if desired.
> >
> > How would it know which one to handle, then?
>
> It has been a while since I looked at this part of the code, and I suspect there is not enough coordination between the potential
> callouts that hooked into ap_run_process_connection(). But I had gotten the idea that in theory, each callout could look at the
> incoming request (raw PDU) and determine if it knew how to handle it. Returning DECLINED until the right protocol handler was
> found. Basically laying the foundation for apache to become a server of many protocols, through a universal addr/port. ;-)
>
> I agree that different protocols would normally use separate ports, but prehaps there are issues getting through a firewall.
> Instead of being data sensitive, I suppose each process_connection callout is expected to look at the fd/port used and DECLINE based
> on that.
Exactly.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: beta?
Posted by David Williams <dw...@cisco.com>.
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> David Williams wrote:
> >
> > > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > > > > > James Sutherland wrote:
> > > > > > [snip]
> > > > > > >
> > > > > > > The question is, what "protocol" to use? Just sending a
> > > > > struct describing
> > > > > > > what's going on is one option; have each process send to a socket
> > > > > > > (UDP??) with the monitoring module/process running on?
> > > > > >
> > > > > > This is solution that works.
> > > > > >
> > > > > > However, I also miss still a protocol field in the
> > > > > > server_rec. If Apache can support multiple protocol
> > > > > > via protocol modules it is my opinion that each
> > > > > > server ('server_rec') needs to know which protocol
> > > > > > it serves.
> > > >
> > > > Seems that each server does need to know which protocol it is capable of
> > > > serving. And in cases where it supports multiple ones, use the
> > > > request_rec->protocol field to determine how to handle that particular
> > > > request.
> > >
> > > Now you've lost me ... a "server" in this context is a binding of an IP
> > > address and port - it inherently "knows" what it should do through the
> > > configuration (which is derived from that binding).
> >
> > I am under the impression that ap_hook_process_connection() was provided to
> > allow non-http protocol modules to hook into the processing path?
>
> Yes.
>
> > So that a
> > given server process (e.g. child_main() in prefork.c) could handle multiple
> > protocols, which could all be sent to the same port if desired.
>
> How would it know which one to handle, then?
It has been a while since I looked at this part of the code, and I suspect there is not enough coordination between the potential
callouts that hooked into ap_run_process_connection(). But I had gotten the idea that in theory, each callout could look at the
incoming request (raw PDU) and determine if it knew how to handle it. Returning DECLINED until the right protocol handler was
found. Basically laying the foundation for apache to become a server of many protocols, through a universal addr/port. ;-)
I agree that different protocols would normally use separate ports, but prehaps there are issues getting through a firewall.
Instead of being data sensitive, I suppose each process_connection callout is expected to look at the fd/port used and DECLINE based
on that.
>
> > > > > ?? So how come mod_echo works without one of these?
> > > >
> > > > mod_echo might not be the best example, since it doesn't care about the
> > > > protocol at all, simply echoing what was received.
> > >
> > > Errr ... and how is this not a protocol? Wouldn't you be a little upset
> > > if your webserver thought that's what it should do?
> >
> > I meant mod_echo is not a protocol in the sense that it cares about request.
> > It would treat
> > GET http://www.foo.org HTTP/1.1
> > METHOD_X New_Transport_Protocol:Resource_locator NTP/1.0
> > the same and hijack the incoming request. Where as a more protocol aware
> > module would examine the PDU and decline the request if it doesn't
> > understand it. Giving ap_process_http_connection() or other protocol
> > modules a chance to handle it.
>
> Ah. You are talking about a protocol of a different kind. Clearly you
> have to know in advance that the client is going to select a protocol in
> its request - and _that's_ the protocol you handle in
> ap_hook_process_connection(). If you then want to hand off to a
> sub-protocol you need your own hooking mechanism to do that, I'd say
> (which would be dependent on the initial protocol). This would,
> presumably, use an optional hook (damn, can I rename generic hooks to
> optional hooks without getting shot?).
Yes! One of the nice things about 2.0 is the ability for a module to define a new set of hooks to be plugged into.
-david
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
>
> > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > > > > James Sutherland wrote:
> > > > > [snip]
> > > > > >
> > > > > > The question is, what "protocol" to use? Just sending a
> > > > struct describing
> > > > > > what's going on is one option; have each process send to a socket
> > > > > > (UDP??) with the monitoring module/process running on?
> > > > >
> > > > > This is solution that works.
> > > > >
> > > > > However, I also miss still a protocol field in the
> > > > > server_rec. If Apache can support multiple protocol
> > > > > via protocol modules it is my opinion that each
> > > > > server ('server_rec') needs to know which protocol
> > > > > it serves.
> > >
> > > Seems that each server does need to know which protocol it is capable of
> > > serving. And in cases where it supports multiple ones, use the
> > > request_rec->protocol field to determine how to handle that particular
> > > request.
> >
> > Now you've lost me ... a "server" in this context is a binding of an IP
> > address and port - it inherently "knows" what it should do through the
> > configuration (which is derived from that binding).
>
> I am under the impression that ap_hook_process_connection() was provided to
> allow non-http protocol modules to hook into the processing path?
Yes.
> So that a
> given server process (e.g. child_main() in prefork.c) could handle multiple
> protocols, which could all be sent to the same port if desired.
How would it know which one to handle, then?
> > > > ?? So how come mod_echo works without one of these?
> > >
> > > mod_echo might not be the best example, since it doesn't care about the
> > > protocol at all, simply echoing what was received.
> >
> > Errr ... and how is this not a protocol? Wouldn't you be a little upset
> > if your webserver thought that's what it should do?
>
> I meant mod_echo is not a protocol in the sense that it cares about request.
> It would treat
> GET http://www.foo.org HTTP/1.1
> METHOD_X New_Transport_Protocol:Resource_locator NTP/1.0
> the same and hijack the incoming request. Where as a more protocol aware
> module would examine the PDU and decline the request if it doesn't
> understand it. Giving ap_process_http_connection() or other protocol
> modules a chance to handle it.
Ah. You are talking about a protocol of a different kind. Clearly you
have to know in advance that the client is going to select a protocol in
its request - and _that's_ the protocol you handle in
ap_hook_process_connection(). If you then want to hand off to a
sub-protocol you need your own hooking mechanism to do that, I'd say
(which would be dependent on the initial protocol). This would,
presumably, use an optional hook (damn, can I rename generic hooks to
optional hooks without getting shot?).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff