httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: One more try with the response to client question
Date Wed, 15 Aug 2001 12:56:52 GMT
In a message dated 01-08-15 10:05:32 EDT, you write:

> Trying again and making sure that I didn't send HTML... I mean it this
>  time...  I have been having problems with outlook.  Anyways I have
>  made a little progress in this area and I have found that I am not
>  getting a carriage return after the POST data from the NetCache
>  server.  Should this matter?  I though that was the problem until I
>  realized that in other test I POST plenty of data that does not have a
>  CRLF and have no problems.

Ok... real quick... here is what's probably happening...

Way back when Netscape decided to fix a problem with Server-side
CGI whereby if someone's CGI was using fgets() of some other call
that reads stdin and was EXPECTING all input to be terminated with
CR/LF then the CGI script would hang waiting for data on a POST
request. It wasn't clocking 'Content-length:' correctly. Unfortunately,
Netscape didn't add the extra CR/LF at the end of the POST data
to the 'Content-Length:' so you are always getting 2 bytes more
than is indicated in the POST request header.

That's called 'out of band' data and you really have no way of
knowing if it's going to be there or not.

This 'out of band' deal continues to this day but there is a catch...
Different browsers will do different things.

Netscape browsers still automatically add these 'out of band'
characters at the end of POST data pretty much all the time.

MSIE 5.x will NOT automatically add CR/LF unless you set
yourself into 'Proxy' mode ( and use either HTTP/1.0 or HTTP/1.1 ).

I think what might be happening is that when you test directly
to Apache you are NOT sending CR/LF with MSIE but when
you set yourself to Proxy to the NetCache server you suddenly
are ( or vice versa? Don't know exactly what you are doing. ).

Either way... this could be part of the problem. The NetCache
servers are not fully HTTP/1.1 compliant anyway so it sounds
like a 'Keep-Alive' issue as well.

Important question: Is whatever you are using to RECEIVE this
POST data expecting the final CR/LF, or no? Exactly how
are you 'processing' the POST data? Perl, Shel script, Java, what?

Also... you are at risk of getting slammed for asking 'irrelevant'
questions on this forum. These guys are way too busy at the
moment to deal with this so please POST any response 
directly to me and I'll see if I can help you. I know the NetCache
stuff pretty well and have solved similar HANG issues and 
it all came down to NetCache not being HTTP/1.1 compliant.

Send all further responses directly to TOKILEY@aol.com
unless someone else from the list jumps in and says it's
ok to continue this thread on this forum...

Yours...
Kevin Kiley
TOKILEY@aol.com

Mime
View raw message