--- Enno <[EMAIL PROTECTED]> wrote:
> > Just so I'm clear on this, you think the customers > > that are having the problem are using a > 2.0.55-based > > proxy and my end is simply waiting for the rest of > the > > data? I am assuming the one client is using a > > Symantec proxy because of the HTTP_VIA env > variable -- > > but I don't know if that product is based on > apache or > > not. > > > > HTTP_VIA="1.0 WEBSENSE01SA, 1.0 > Symantec_Web_Security > > (3.0.0.52)" > > hmm, I wouldnt go so far to say symantec is selling > apache > as a proxy... but it is possible that the symantec > proxy has > the same bug... > > also, please note that I located that bug in systems > with reverse > 2.0.55 proxies, using ssl on both ends. > The form is non-SSL . It doesn't sound like the same problem. > > Is there a third-party URL that I can ask my (big > > company) users to test against to prove to them it > is > > not at my (small company) end? > > any form where you can post a large amount of kbs > (eg 30kb) > of data will do just fine. (or even upload a 100kb > file using a form) > > > Would I see the problem at my end if I used > something > > like tcpdump to capture the packets? What am I > > looking for? > > > > Tom > > I'd guess so, I never had to go through the troubles > as I > was able to locate the problem quite quickly without > it. The CGI script does get kicked off -- I added file logging to the script to see where it was hanging and found the problem at the "new CGI" line. If it is a chunking problem, does Apache not recombine the chunks before launching the script? If so, then I wouldn't expect to see the script launch in the first place. Please correct me if I'm wrong. Is there some code I can put in the script to trace or confirm the health of the POSTed call without initiating CGI.pm? Tom __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
