My bright idea, the one where I do a HEAD request, and then decide how to handle it?
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?
When the Netscape web server first came out, about 58 web-years ago, they touted the ability to write server-side scripts in a new language called “javascript”. Well, guess what? now there’s
v8cgi from from google, which lets you do the same thing.
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?
Okay, the latest: I’ve fixed the incomplete headers problem, and found a solution to proxying non-XML resources: not to do it at all!
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:
Keep checking back, I’ll keep you updated. If you feel like contributing, let me know.
The Links:
I have a version of klortho that’s able to parse its PATH_INFO, grab the XML that’s located there, and apply the transformation that’s in the processing instruction, if such exists. That’s cool.
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.
