Apparently, I did not read the AJP13 spec nor my original code very closely:
Note: The content-length header is extremely important. If it is present and non-zero, the container assumes that the request has a body (a POST request, for example), and immediately reads a separate packet off the input stream to get that body.
Here I was
requesting the first block. Anyway, a quick and easy fix.
ajp-wsgi is moving along... and actually, development has slowed down immensely (a marked sign of stability?). I've converted all Python WSGI applications on my server to use it now. It may just be psychological, but I
do notice application responses being a bit snappier. But who knows.
Trac seemed to be the most non-trivial to convert. It doesn't provide a ready-made application factory to create the WSGI app object. I basically had to mimic (using my config options) the operations that its main() method performed. Other applications (my own blog & shorten projects, moinmoin) had readily-available app objects though. And I'm also glad to say that Paste Deploy-based apps are easily deployed with
ajp-wsgi as well.
Anyhow, I went ahead and decoupled the C WSGI code from the AJP code today. Now the next time I'm bored, I think I'll write drivers for both ends of an SCGI connection. It would be interesting if I could write that FastCGI->SCGI adapter wholly in C (using the standard C FastCGI dev kit). Actually, I guess I should check if there's already a C SCGI implementation...
