Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Odd Header Behavior |
Page Previous 1, 2 |
| Author |
|
tdonovan
Moderator
Joined: 17 Dec 2005
Posts: 611
Location: Milford, MA, USA
|
 Posted: Fri 18 May '07 21:09 Post subject: |
 |
|
hmmmm... running out of ideas here.
If I understand right - when you get the problem, you have two "200 OK" status lines:One that shows up as a bona-fide header: HTTP/1.x 200 OK
(probably from your application somehow)
And another one that gets displayed on the screen: HTTP/1.1 200 OK
(probably the Apache-generated one) Since the second one and all the headers which follow it are treated as content, the browser never interprets them correctly.
The most likely culprit in the example you gave is {your_webroot}/auth/common/ids.cgi
If ids.cgi is an executable binary, try this: | Code: | | strings ids.cgi | grep '1\.x' |
to see if it contains the "1.x".
If not - maybe your FireFox plugin is changing "1.1" to "1.x" when you view it.
If you can, try the site without SSL, which might produce different behavior.
Without SSL you could use tcpdump to see the actual packets: | Code: | | tcpdump -Aqs0 tcp port 80 |
but you would need to test with a browser on a different system so the request would actually go through the network and be captured by tcpdump.
If none of these things help, alas, whoever supplies your ERP system are probably the only ones who can really investigate & explain this phenomenon.
-tom- |
|
| Back to top |
|
|
|
|
|
|
