#1768 closed defect (fixed)
WFS: CR/LF in XML post body blocks reply of mapserve.exe cgi
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | MapServer CGI | Version: | 4.8 |
Severity: | normal | Keywords: | |
Cc: | jmckenna@… |
Description
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
Attachments (1)
Change History (9)
by , 18 years ago
Attachment: | test_Mapinfo_CRLF.zip added |
---|
comment:1 by , 18 years ago
Status: | new → assigned |
---|
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.
comment:2 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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).
comment:3 by , 18 years ago
Cc: | added |
---|
comment:5 by , 18 years ago
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?
comment:8 by , 18 years ago
Cc: | added |
---|
Note:
See TracTickets
for help on using tickets.
Test cases for CR/LF bug