Hi everyone, Thanks for the info. Looks like an apache filter is the way to go. Noah, you're right. Adding a CGI would mean an additional CGI in front of the existing one. We have not checked performance there, but I don't see it being pretty. Rewriting the existing CGI is tricky, but I can see how it would be the only other way to do it (other than writing an apache filter). I'll look into the filter option for a while. Thanks for the help! Cheers, Fernando On Mon, 21 Mar 2005 18:13:01 -0500, Noah <sitz@xxxxxxxxxxxx> wrote: > On Mon, Mar 21, 2005 at 03:15:55PM -0500, Joshua Slive wrote: > > On Mon, 21 Mar 2005 14:43:33 -0500, Noah <sitz@xxxxxxxxxxxx> wrote: > > > On Mon, Mar 21, 2005 at 12:20:08PM -0500, Joshua Slive wrote: > > > > > Writing an intermediary CGI that would take the headers and modify > > > > > before sending to the customer's CGI is not something we want to do, > > > > > as performance in this environment is critical. > > > > > > > > Have you actually benchmarked the performance hit? I'd be surprised > > > > if this was actually the factor make or break your application. > > > > > > Depends; if it's a perl script (and there's no mod_perl involved) it can > > > definitely be a make/break. Wanna see pictures of melted servers? *whips > > > out wallet* > > > > But the thing is, the cost of the perl script is already sunk. The > > script to do the variable substitution could be a simple shell script > > or a compiled executable. All it costs is one extra program call. > > I got the impression that the thought to add a CGI into the execution > stream which would muck with the headers prior to the request being > sent to the customer's (read: a different) CGI. If this is the case, a > second CGI would be getting called, (obviously =) ) reducing performance. If the plan was to incorporate the headermunging into an existing CGI, I'd agree with you; it's just not the impression I got from the original email. > > --n > > -- > <huey> dd of=/dev/fd0 if=/dev/flippy bs=1024 > <huey> ^^^ Making Flippy Floppy > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > -- Fernando Montenegro, CISSP - fsmontenegro@xxxxxxxxx Markham, ON, Canada --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|