Weird HTTP heders in Html Body

[c_klar]

HI,

When running the following script on certain web browsers in displays
HTTP headers in the body of the page.

_______________________
TestPerl.pl:
- - - - - -
print("HTTP/1.0 200 OK\n");
print("Content-type: text/html\n\n");

print "a" x 2000;
_____________________

Then in the browser (Mac IE or perl get).
____________________
http://www.mysite.com/TestPerl.pl

- - - - - - -
aaaa...aaaaaaaHTTP/1.1 200 OK
Connection: close
Date: Thu, 17 Mar 2005 20:27:19 GMT
Content-Type: text/html
Server: Microsoft-IIS/6.0

aaa....aaaa
_____________________________________

Webserver: IIS6
Platform: win3k
Perl: v5.6.1 built for MSWin32-x86-multi-thread, Binary build 635
Browser: IE on Mac, or Perl Get


Thanks,
Chaim Klar

 

[Chris Mattern]

HI,

When running the following script on certain web browsers in displays
HTTP headers in the body of the page.

_______________________
TestPerl.pl:
- - - - - -
print("HTTP/1.0 200 OK\n");
print("Content-type: text/html\n\n");

print "a" x 2000;

That's not legal HTML. You throw any old crap at the browser,
you get any old crap back.


--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[c_klar]

O' Please,

 

[Chris Mattern]

O' Please,

"O' Please," what? Garbage in, garbage out.

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[A. Sinan Unur]

(e-mail address removed) wrote in @l41g2000cwc.googlegroups.com:

O' Please,

O', duh! Like ...

Sinan.

 

[Gunnar Hjalmarsson]

When running the following script on certain web browsers in displays
HTTP headers in the body of the page.

TestPerl.pl:
- - - - - -
print("HTTP/1.0 200 OK\n");
print("Content-type: text/html\n\n");

print "a" x 2000;

What you seem to be trying to do is running a non-parsed header CGI
script. Have you tried renaming it to nph-TestPerl.pl?

If that's not your intention, i.e. if you just want to run a usual
("parsed") script, drop the first print() statement.

Note that your problem is about CGI, not Perl, so it's off-topic here. I
would recommend that you study a beginners tutorial about CGI scripts in
Perl.

http://cgi.resourceindex.com/Documentation/CGI_Tutorials/

 

[Tad McClellan]

O' Please,

O'killfiled.

 

[c_klar]

ok, in my initial posting i also listed Perl Get as one of the
utilities which got me this error too (it is not a browser strictly
speaking so it does not need to be legal html).

I intentionally made this bare bone script to eliminate all the odds so
I focus on the cause of the issue.

Then I realized that I have a ISAPI compression filter on my webserver
and I guessed let me give it a shot and turn it off maybe the issue has
to do with it, guess what once I turned it off the problem disappeared.


so I contacted the company who wrote this ISAPI filter, and the rest
I'm just attaching.



Chaim,

I have posted a detailed account of this problem to MS IIS news groups
a year ago (a few times) and got no response. My original post
immediately follows this message. Essentially, I believe this to be a
bug in IIS 6. To work around the bug, disable 'Fast data passthru'
PipeBoost option (in Advanced Options).

I think the reason why you only see this in *some* browsers is that
other browsers mistakenly interpret the HTTP header data inside the
response as a start of a *new* response, and I would not blame them for
doing so since there is not Content-Length field in the response, and
they are attempting to implement an (uncommon) extension. Or these
browsers send something in the request that triggers the bug.



....
_________________

Posting: Newsgroups: microsoft.public.inetserver.iis
Sent: Friday, February 13, 2004 3:08 PM
Subject: Problem: IIS 6, external CGI (.exe) + RAW-WRITE ISAPI filter



There seems to be a problem with IIS 6 W3SVC (build 3718; WP Isolation
mode)
under the following conditions:
1) servers is gatewaying to an external CGI processor (perl.exe,
whatever.exe) to process a script;
2) there is an active ISAPI filter present that binds to
SF_NOTIFY_SEND_RAW_DATA notification;
3) this filter calls
ServerSupportFunction(SF_REQ_DISABLE_NOTIFICATIONS) to
disable the SF_NOTIFY_SEND_RAW_DATA notification while processing this
notification

When all these conditions converge, what you get is a really confused
IIS
that starts prepending the HTTP response header to every data packet it
sends out after the filter disables the RAW-WRITE notification (while
processing this request).
Please see attached zip for details and code.

How would I go about reporting this and getting this fixed?
Thanks in advance.

 

[c_klar]

Thanks to everyone, the issue was resolved as you can see the
resolution in my previous posting.