Not gonna work. Things just get too confusing in the case of a POST.

I’ll have to do some major re-thinking, and revert some things back the way they were before.

Nobody said this would be easy, now, did they?

Big deal? Maybe it is. Javascript has come a long long way from the days when it was just used for rollover images. Imaging applying the power of jQuery to your server-side development. Is this an easy way to reach the nirvana of functional web programming I’ve been seeking?

Here’s the way klortho now behaves. It parses the request URL, does a HEAD request on it with the original HTTP headers from the user’s browser, and then takes 1 of 3 actions. If the returned status code is anything other than “200 OK”, it returns the headers it receives. If it gets a “200 OK”, but the “Content-Type” is anything other than “application/xml” or “text/xml”, it sends a “301 Moved Permanently” status, with a “Location” header pointing the user’s browser to the URL parsed from the “PATH_INFO”. This tells the user’s browser that klortho is not interested in brokering this request, and to kindly just get the resource directly from now on, thankyouverymuch. Only if it has a “200 OK”, and the right XML content type does it go ahead and retrieve the body of the response, and process and return it.

Still unfinished:

1. POST requests. This is a biggie. If the checks succeed, klortho will have to pass in the POSTed data it receives. libCurl has a good tutorial on this. It’s should be straightforward.
2. Some response headers may need to be adjusted on the way out, the ones that relate to proxying.
3. Authentication will need to be transparently passed through

Keep checking back, I’ll keep you updated. If you feel like contributing, let me know.

The Links:

• The “Show” script, without klortho
• The “Show” script, with klortho
• The “Rate” script, without klortho
• The “Rate” script, with klortho
• klortho source

I’ve been using this to work with my python band name generator, and I can get random band names to show, and that’s really great, because I can use the needs I discover while working on this band name program to decide which as yet unimplemented parts of klortho I’ll need to implement, which brings us to my roadblock.

I’m writing the python script (called “Rate”) that will take in POSTed parameters to update the ratings for all the words in the previously displayed band name, and then redirect back to “Show”. klortho needs to do two things that it can’t do yet in order for this to work: it needs to understand POSTed data, and pass it to the sub-request, and it needs to recognize redirect status codes from the sub-request, and pass them back out, along with the appropriate headers.

I started small and modest. “Rate” just issues a redirect to “Show”. If you call the script directly, it works. Nothing I try in klortho will pass that redirect out. I run into a brick wall of of “500 Server Error”. The server error log reliably reports that FasctCGI is complaing that I’m sending incomplete headers. Is it a Dreamhost server config issue? What’s going on? What do I try next to learn more about what’s really happening?

I see two roads, and I may follow them both at the same time. I can create a little dummy FastCGI in c, that does nothing but issue hard-coded redirects. I’d leave out all the other things that klortho is doing, and tweak away at the stripped down version until I get it right, then put what I’ve come up with back into klortho. The other idea I’ve had is to write another version of klortho from scratch, and concentrate on acting as a fully transparent proxy, which will pass all the appropriate headers in and out, handle authentication and POST data and file uploads and any status code the sub-request might throw at it, and then add the XSLT transformations back into it.

• The “Show” script, without klortho
• The “Show” script, with klortho
• The “Rate” script, without klortho
• The “Rate” script, with klortho
• klortho source