Alvaro Lopez Ortega wrote:
Eric S. Johansson wrote:

No, it isn't supported.  At this moment you can define different
kinds of error handler and you can use different actions for each
error code, but it is virtual server wide.

I didn't imagine that could be a requirement for somebody.

Anyway, you could add a php as error handler, and do different thing based in the referer.. It is just an idea. :-)

PHP is the sendmail (in terms of security) of the Web set. ;-)

the reason for the error handler requirement is that I am abusing it
horribly.  It's one of those things you really shouldn't do it bought
when you find out you can, you do it anyway.

I am currently modifying a package called aether.  yet another
simplified market for creating Web pages.  I have expanded its to
simplified CGI creation and so far, so good.

aether typically uses URLs like http://www.demo.com/ae/apple and apple
refers to an internal page which is rendered into HTML before display.
Personally, I find this ugly as I believe all CGI's should be invisible.
 So when someone types http://www.demo.com the CGI is run rendering the
appropriate page.  The same is true for: http://www.demo.com/apple.  in
both examples, the CGI gets the local URL ('/' and '/apple'
respectively) so I can find the appropriate local file for rendering.

therein lies the abuse of the error handler.  Since none of the pages
referred to by the URL exists, it triggers a 404 response which invokes
the error handler which passes the local URL to the CGI so it renders
the page and returns the page as valid page with a 200 response instead
of a 404 response.  Really cool but horrible abuse.  ;-)

the other cool thing is if you can put in multiple error handlers based
on different URLs, you can have different aether contexts and different
styles of pages.



REDIRECT_URL properly set during a 404 events


I'm not sure about what you want to mean with this.

it's an environment variables that by Apache in response to a 404. I use it to pass the local part of the URL to CGI program.


the ability to log X-Forwarded-for: addresses in place of the
upstream proxy address.


I don't understand this requirement.  What do you want to do with
that header?

I have multiple web sites on a couple different machines sitting behind a single IP address. I redirect based on name-based virtual domains using pound. normally access logs just show the proxy address which is not very useful. But since Pound uses the X-Forwarded-for: header for telling downstream servers where the request really came from, it would be nice to use it in the logs. Obviously, one must be extremely careful in doing so since it can be forged. The usual solution is to put in ACL that require you to specify the proxy to treat as authoritative.


setting environment variables on per directory basis before calling
a CGI.


It isn't supported, but seems to be a 5 minutes long hack in handler_cgi. :-)

and other words, if I do it, you'll take the change. :-)


Also, where do you hide your configuration documentation?


At this moment the only resource is the configuration example files that are distributed with the source tarball. I know we have to
start distributing a more friendly documentation..

that would be helpful. Thanks for the feedback. If I can find a way to
make things were the way I want regarding aether, it sounds like the switch would be worth it.


---eric



--
http://www.wired.com/wired/archive/13.03/view.html?pg=5

The result of the duopoly that currently defines "competition" is that
prices and service suck. We're the world's leader in Internet
technology - except that we're not.
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee

Reply via email to