Quintin, Yes, what you suggested is similar to what I proposed in my inital post and I agree that implementing AJP in PHP would be a path best not traveled.. :-) Was planing on using the memcached PHP client as a road map to map the mod_jk or mod_proxy_ajp code into.. John Gentilin
--- On Wed, 8/13/08, Quintin Beukes <[EMAIL PROTECTED]> wrote: From: Quintin Beukes <[EMAIL PROTECTED]> Subject: Re: AJP and PHP To: "Tomcat Developers List" <dev@tomcat.apache.org>, [EMAIL PROTECTED] Date: Wednesday, August 13, 2008, 11:46 PM Hey, I once looked for an AJP implementation for Java, and what I found was that there is only one implementation, and that is for Apache. >From here, it's not a very complex protocol. It's basically a "compressed" http implementation. The concepts are very similar, with GET/POST requests, Headers, body, etc. It won't be a quick one though, as it's very binary, and this would end up messy and buggy in PHP if not done properly (from personal experience I found that PHP tends to get very messy very quickly with these type of things). If I were you, I would rather make a PHP module that makes use of mod_proxy_ajp to do the requests. PHP modules are not difficult to write. The idea I'm talking of goes something like this. 1. Make a PHP module that exposes a function ajp_request($target_url, $method, $encoding, mixed $data) (or more than one for different call types, ex. form encoded post, raw post, get, etc.) 2. Then inside this function (on the module or "c" language level) you would hook into mod_proxy_ajp and do a request, returning a stream from which can be read. For raw posts you can even expose an output stream. This function would also return a resource handle, which can be used to set headers. Just figured I'd share this with you. This is definitely the route I would go. Especially since you'll benefit from the 3rd party implementation, which would result in your application effectively growing as their's grow (Their bug fixes become your bug fixes). And on top of this you already have a high-performance, mature AJP implementation to work from. If you do decide to implement this, you should definitely make it open source. I'm sure if you did PECL you would have. And I'm sure it would even become a standard PHP module, as it can be very useful, especially for web services (like you mentioned). Q On Thu, Aug 14, 2008 at 7:53 AM, John G <[EMAIL PROTECTED]> wrote: > Why scary, all I am trying to acheive is persistant connections to a servlet from PHP.. > > The same interface is used from Apache to a servlet, both in mod_jk and mod_proxy_ajp. > It seems less clumsy and more efficient than implementing a curl call and this same > persistant interface could also be used as a Web Service transport instead of JSON.. > > John Gentilin > > --- On Wed, 8/13/08, Jim Manico <[EMAIL PROTECTED]> wrote: > > From: Jim Manico <[EMAIL PROTECTED]> > Subject: Re: AJP and PHP > To: [EMAIL PROTECTED] > Date: Wednesday, August 13, 2008, 10:35 PM > > scary man - this cries for a web service interface. > > - Jim >> I have a project where our presentation layer is in PHP and the business > logic is Servlet based.. The interface is JSON via a CURL call.. >> >> I was thinking that I could gain some efficiencies if I created a native > AJP implementation as a PHP PECL module using memcache and mod_jk as templates > and create a >> persistent connection pool. That way I can dump the curl call.. >> >> Looked all over to see if this has been done before, but came up empty... >> >> Any thoughts on this ?? >> >> Thanks >> John Gentilin >> >> >> >> >> >> >> >> > > > -- > Jim Manico, Senior Application Security Engineer > [EMAIL PROTECTED] | [EMAIL PROTECTED] > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security™ > Securing your applications at the source > http://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY. > http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > > > > > -- Quintin Beukes
