I am working on a port of Apache 1.3.20+mod_ssl 2.8.4 to TPF. I'm still struggling to get it to correctly support cgi script processing in secure mode from a Netscape browser.
One key difference I see between Netscape and other browsers is that Netscape sends a POST request in four chunks in two TCP packets. (In Opera and IE, the POST is in one chunk, one packet.) The first TCP packet has one chunk and the 2nd TCP packet has three chunks. Here I'm defining a chunk as something starting with 0x170300[length][encrypted data]. The first chunk has the request and the mime headers, the 2nd and 3rd chunk appear to be blank lines (or just CRLFs) and the 4th chunk has the content-type, content-length and form data. From what I understand of HTTP and TCP, this seems a valid thing to do. I put a trap in SSL_read to see what it is reading after the decrypt, and I see only the first chunk; SSL_read is not called again to try to read more before the connection shutdown. I see the comments in the file ssl_engine_io.c and wonder what the implications are on TPF. I tried compiling both with and without SSL_CONSERVATIVE and it makes no difference. The platform closest to TPF is OS/390; they both run on IBM zSeries processors (ebcdic). Running Apache+mod_ssl on OS/390, cgi scripts works fine from Netscape, so that would seem to rule out any bugs in, say, ebcdic translation. There must be some platform specific nuances here relating to the 'sucking' that ssl_engine_io.c does or with processing chunks. If anyone has words of wisdom of potential areas where the problem is, I'm all ears. Meanwhile I'll continue to rummage deeper into the code. Regards, Evan Jennings TPF Development, IBM Corp. Poughkeepsie NY (845) 435-1918 ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
