Alvaro Lopez Ortega wrote:
I don't know! It seems a twisted configuration for me too, but it
seems like you want to do so.. :-) I'm still trying to figure out
what are you trying to set up.
ever have one of those projects where somebody says "hey, this is a good
idea let's do it!" and you find yourself left holding the code? I was
so busy expanding its capabilities, that when I looked around and saw I
was by myself, I kept going.
here's the original site and documentation.
http://www.logarithmic.net/pfh/aether
when I get them of my documentation, hopefully it will be a
significantly easier to use Web development environment for small to
medium scale projects. far too often many of the web frameworks don't
reduce complexity, they only move it sideways. For example, in
Cherokee, you have made a web server simpler to manage and configure.
Apache on at the hand keeps gluing on turds.
the main problem I see with the old implementation (aether) was the
expectation one would use a 404 handler as a way of trapping and
executing CGI. It's an interesting technique. Although it tends to
junk up your log files with false 404 errors not to mention binding you
to Apache until the heat death of the universe.
I want to change that. And I've discovered that it's not easy. The 404
handler really is the easy way out if it behaves properly. however, it
leaves you feeling slightly icky :-)
I've also discovered that Akasha is also a great way of finding out bugs
in web servers. For example using a simple shell script to dump
environment variables, I discovered that path_info is not handled the
right way.
(note: I use port 8080 for testing)
http://localhost:8080 page_info doesn't exist
http://localhost:8080/ page_info doesn't exist
http://localhost:8080/foo page_info = foo
http://hoohoo.ncsa.uiuc.edu/cgi/env.html
""" The extra path information, as given by the client. In other words,
scripts can be accessed by their virtual pathname, followed by extra
information at the end of this path. The extra information is sent as
PATH_INFO. This information should be decoded by the server if it comes
from a URL before it is passed to the CGI script
"""
Whether or not this means that there should be a path_info, I believe it
means that if there is, the path remaining includes the '/'. This is
not too big a deal for me because I have worked around it.
Another problem I found is that if the CGI returns a 404 error as well
as its own 404 display, I get the server's 404. Maybe this is a patchy
specific but I was under the impression that the CGI program had the
option of returning its own data in the case of errors detected.
I've also noticed a similar problem with 500 errors. Nothing from
standard error is placed into the log. I'm currently debugging a submit
button problem. I get a 500 error message and nothing else so I am
debugging relatively blind. after spending a bit time looking over the
CGI handler, I'm relatively certain that the way you handle the 404 and
500 error codes are part of the problem.
not sure exactly how to fix it yet but that's where it lies.
the need to do this is an artifact of the CGI environment. CGI is
not a position to tell the web server what to do. maybe on the
other hand, I should be looking at making my own module. One which
embeds Python and implements the logic I want.
I have got a Python module, but it is unpublished by the moment. I
want to get the FastCGI stuff finished before releasing new handlers,
we should try to have just one instable component at a time. :-)
chicken. ;-) actually, I can't blame you because I would be probably
one of your most "stressful" users.
---eric
_______________________________________________
Cherokee mailing list
Cherokee@lists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
