Looking again at OS/390 for comparison, I did misstate the flow. Below are the actual intercepted SSL_read outputs on TPF. The "S_r: " prefix indicates each SSL_read:
S_r: POST /cgi-bin/cgi-forms HTTP/1.0 Referer: https://1.2.3.4/cgiform.html Connection: Keep-Alive User-Agent: Mozilla/4.77 .en. (Windows NT 5.0; U) Host: 1.2.3.4 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,de Accept-Charset: iso-8859-1,*,utf-8 The same thing on OS/390 shows me: S_r: POST /cgi-bin/test-cgi HTTP/1.0 Referer: https://5.6.7.8:8443/cgiform2.html Connection: Keep-Alive User-Agent: Mozilla/4.77 [en] (Windows NT 5.0; U) Host: 5.6.7.8:8443 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,de Accept-Charset: iso-8859-1,*,utf-8 S_r: Content-type: application/x-www-form-urlencoded Content-length: 9 S_r: S_r: entry=123 So, the question is why is TPF not seeing the rest of the body that tells it there is more data to read? I can tell from an IP trace that it is sent from the client (in a packet containing three 170300's). I'll continue to examine the code in ssl_engine_io.c to see if the problem relates to the sucking and buffering it does. Regards, Evan Jennings TPF Development, IBM Corp. Poughkeepsie NY (845) 435-1918 Eric Rescorla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: cc: owner-modssl-users@ Subject: Re: engine io question modssl.org 09/27/2001 05:37 PM Please respond to modssl-users "Evan Jennings" <[EMAIL PROTECTED]> writes: > 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. This is awfully suspicious sounding. HTTP posts consist of headers followed by a pair of CRLFs followed by a body. If there is no Content-Length header than the body is assumed to be zero length. Thus, if you're getting a request that looks like this: ---------------------------- GET /url HTTP/1.0 Other-Header: foobar Even-Another-Header: Something Content-Type: mumble/frotz Content-Length: Some-number-of-bytes Form-data ---------------------------- Then something is seriously wrong. Are you sure that's what's going on? > 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 haven't checked the code but my memory is that HTTP servers typically try to read only the headers and (when there's a body) leave that on the wire until the script reads it. I would imagine that mod_ssl behaves roughly the same way. Except that the data needs to be processed by mod_ssl to decrypt it. So, what you may be having here is a problem establishing the pipe between mod_ssl and your CGI script. -Ekr ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
