Someone in Japan is trying to use CGI scripts for some old Perl
subsystem, and was asking why nscgi was corrupting their data.
Their perl scripts were trying to output in EUC-JP encoding.
I looked at nscgi.c, and saw that it calls Ns_WriteConn, which
assumes that the content is living as UTF-8. It then applies
the encoding translation it thinks is needed to output
to the desired output encoding, (which is probably ISO-8859-1, since
no one else sets it I think).
Anyway, the easiest fix was to make nscgi just output raw bytes, and
let the CGI script author figure out the encoding problems.
Here's a patch that does that, just change one line of nscgi.c
in aolserver/nscgi/nscgi.c
copy:
do {
/* status = Ns_WriteConn(conn, cgiPtr->ptr, cgiPtr->cnt); */
status = NsWriteConnRaw(conn, cgiPtr->ptr, cgiPtr->cnt);
} while (status == NS_OK && CgiRead(cgiPtr) > 0);
/*
Alternatively, people who want to output cgi data in other encodings
could generate UTF-8 in their scripts, and we could make sure that
AOLserver gets the information about the desired target encoding
(probably from the filename extension, or else by reading the
actual Content-type header).
Probably no one cares, since CGI usage is basically obsolete.
