On Tue, 03 Feb 2009, Jenda Krynicky wrote:
>
> 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.
>
> 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
I don't think there have been any changes in PerlIS in this area.
I suspect that the binmode() call doesn't work because the :crlf layer
is special: it is not a real layer, but it just sets a bit on a lower
layer to do the translation. But it looks like the ISAPI code is
executed at a higher layer, checks that the output goes to STDOUT
and passes the data on to IIS instead. Similar things would happen
for STDERR. Seems like a bug.
But why would you want LF -> CRLF translation outside the http header?
For content-type text/html this should not make any difference in the
body of the response.
Cheers,
-Jan
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
