tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John G <johngh...@yahoo.com>
Subject Re: AJP and PHP
Date Thu, 14 Aug 2008 07:08:26 GMT
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 <quintin@last.za.net> wrote:

From: Quintin Beukes <quintin@last.za.net>
Subject: Re: AJP and PHP
To: "Tomcat Developers List" <dev@tomcat.apache.org>, johngheli@yahoo.com
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 <johngheli@yahoo.com> 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 <jim@manico.net> wrote:
>
> From: Jim Manico <jim@manico.net>
> Subject: Re: AJP and PHP
> To: johngheli@yahoo.com
> 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
> jim.manico@aspectsecurity.com | jim@manico.net
> (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



      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message