WFS: CR/LF in XML post body blocks reply of mapserve.exe cgi

[fantognini@…]

Configuration: MapServer CGI 4.8.3 (latest MS4W) under IIS 

The issue appeared while trying to have MapInfo work as a WFS client of Mapserver.

When doing WFS queries MapInfo always selects POST, if declared in the
getcapabilities reply. 
In the XML request body it sends, line ends are coded as CR/LF. Other clients
use LF alone. In the test cases I've attached there are 2 line ends: one after
the xml declaration the other after the last tag.

When Mapserv gets a CR/LF it just hangs, probably waiting for more characters to
arrive. My wild guess is that CR get chopped and as the body length doesn't
match the Content-length http header, mapserver.exe just waits for more
characters to arrive.

One way to solve this is to have a wrapper script chop the CR and recalculate
the Content-Length header (cgi variable, actually). With that change, mapserver
gets the request and successfully sends the WFS layer.

Unfortunately I haven't had the chance to test this on other platforms.

Test cases: (added below, hopefully)
WFS request for full layer 'reg_luog' (which will have to exist on the target
machine)
testxml.mapinfo.crlf.txt         original MapInfo request
testxml.mapinfo.lf.txt           MapInfo request stripped of CR

[fantognini@…]

Test cases for CR/LF bug

[fwarmerdam]

I have determined that the problem is when the CONTENT_LENGTH header is
set based on a length include the CRLF's.  It seems that mapserv receives
a stdin handle in text mode, so the CRLFs are translated to LFs on the fly
and so the body is short and the read either hangs waiting for a few more
characters or it fails a "post body short" message is returned.

The solution seems to be to push stdin into binary mode before reading the
post body on win32 systems.  We already do this for stdout in various 
situations.  

I have tested a patch for this and will likely commit it in 4.9 soon.  I'm 
a bit nervous about applying it in 4.8. 

[fwarmerdam]

I have committed the fix in CVS in 4.9. 

I have also updated the FastCGI HOWTO to include forcing stdin into binary
mode on win32 (also adding the rest of the win32 info into the fastcgi
howto).

[dmorissette]

*** Bug 1780 has been marked as a duplicate of this bug. ***

[dmorissette]

I'd like to propose that we backport to 4.8 since this makes WFS with MapInfo
(at least) unusable on Windows.

I have tested a similar fix (big 1780) with both IIS and Apache and it worked
fine so I think it's safe to backport.

Any objections to me backporting the fix?

[fwarmerdam]

I have no objection to a backport of the fix. 

[dmorissette]

The fix has been backported to 4.8, will be in 4.8.4