Jenda Krynicky wrote:
How's it going man - long time no talk.
> I have ActivePerl v5.8.8 build 822 and Windblows Vista Home Premium
> with its builtin IIS (but I see the same behaviour under MS Windows
> Server 2003) and was using the following to print the CGI headers:
>
> print "HTTP/1.0 200 OK\n" if($ENV{'PerlXS'} eq 'PerlIS');
> print "Content-type: text/html\n\n";
>
> Which works with all browsers I know of under both perl.exe and
> PerlIS.dll, but the current version of .Net complains with "The
> server committed a protocol violation. Section=ResponseStatusLine" if
> the script runs under PerlIS. I used a HTTP sniffer and found out
> that if I use perl.exe the \n is turned to CRLF, if I do not, it
> produces just LF. I tried to add
>
> binmode( STDOUT, ':crlf');
>
> but that did not make any difference. I had to create a custom
> PerlIO::via filter.
perl581delta:
...
* The "CR CR LF" problem of has been fixed, binmode(FH, ":crlf") is now
effectively a no-op.
> Why? And has this changed in a later version of ActivePerl? Hopefully
> within the 5.8 series. As I'd like the content to end up having CRLF,
> but do not want to have to place \x0D into all the heredocs and other
> places, I'd rather if I could have \n turned to CRLF under PerlIS.dll
Obviously it's got something to do with the IS version. You should
check for kicks to see what binmode returns (T/F) when you do the :crlf
option on STDOUT. There's no chance that another FH is being used/selected
instead of STDOUT is there (when running in the IS env) ?
Have you tried a test case using CGI.pm to do the headers ? I personally
don't use it, but it would handle the headers for you and if it fails,
you can pretty much chalk it up to PerlIS. CGI always uses CRLF I believe
on Dozers.
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
