On Fri, Oct 22, 2004 at 11:44:44AM -0400, Michael wrote:
This would work if you could assume that since the query object is an Apache::Request object that the user wants to send their HTTP headers using query->header_out() as opposed to header_add(). But this isn't the case. If they are using Apache::Request for their query object, but aren't using my plugin for headers then trying to guess like that causes problems if they decide to use header_add().
Michael,
Just to be sure I'm following you, these issues would be a problem whether you were checking the ref type, using an ENV parameter or checking to see if a plugin is loaded as Rob suggested? I had only considered the cookie side of the equation which is relatively straight forward.
As you've pointed out, the headers are going to be troublesome. It seems like you need to override all of the header_* methods in C::A if we're in a mp environment. Although I've been running my scripts under mp for a couple years now, I'm not very familiar with mod_perl development (thanks to Apache::Registry).
You are correct. Let me make myself clear that I'm not opposed to doing mp development using Apache::Registry, but the Apache API is fairly easy to work with, much more powerful (since you can access all of apache and not just content generation), and much faster. So most of my efforts in this endeavor are because the way C::A currently is, using mod_perl directly is hindered.
I'm going to go a head and try to make my plugin backwards compatible to a degree, but I'm not sure how much that compatibility will be used since I'm encouraging everyone who uses it to use the straight mod_perl api.
Looking at the implementation of header_add, header_props and header_type (which are wrappers for CGI.pm header), I can see where it could be a potential headache to reimplement using A::Request. I wonder how MT is handling this situation; perhaps we can steal some code from them.
If we were designing something from the ground up, like MT did, we could abstract the header situation out (like I'm sure they did). The problem I'm facing is this...
[snip from C::A docs]
The header_props() method expects a hash of CGI.pm-compatible HTTP
header properties. These properties will be passed directly to
CGI.pm’s header() or redirect() methods. Refer to CGI for exact
usage details.
[/snip]
C::A just passes the buck, which wasn't a bad idea at the time, but is really causing me some headaches.
What I'm going to do right now is try and copy CGI.pm's functionality into my plugin for dealing with headers, but send them out using query->header_out() instead. This way, any Apache::Cookie baking, or other previous manipulation either using header_props(), header_add() or query->header_out() will still work.
This will make my job of keeping it compatible harder, but should make everyone happier in the end. :)
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
