Need to set stdin to binary when reading WFS POST requests data

[dmorissette]

Here is the original problem report:

-------- Original Message --------
Subject: 	[UMN_MAPSERVER-USERS] MapServer with MapInfo (WFS)
Date: 	Wed, 26 Apr 2006 15:49:01 -0400
From: 	Léveillé, James
To: 	MAPSERVER-USERS@LISTS.UMN.EDU

Hi all,
 
I'm trying to test MapServer (v 4.8.3), the WFS service, with MapInfo (v 
8.0) and keep having this error message:
 
*"The WFS Server returned data which was neither in the requested format 
nor a recognized WFS service exception : POST body is short.*
*In response to a DescribeFeatureType request, the WFS Server returned 
an invalid feature type."*
 
The GetCapabilities looks fine, and the GetFeature works fine with IE ...
Here is my (simple) MapFile.
 
THANKS A LOT !!!

[dmorissette]

The problem is that readPostBody() needs to set stdin in binary mode before the
call to fread(stdin...)

More details:

- The error "POST Body is too short" was happening with MS4W/Apache on Windows
because the fread call was seeing a EOF, but in the tests I was making,
CONTENT_LENGTH was 382, and fread received only 380 chars.

- Under IIS, the mapserv.exe process was hanging during the fread(stdin...)
call. For some reason it was never seeing a EOF and kept waiting for the two
missing chars.

- Under Linux, everything was working fine.

After investigation, it seems that MapInfo includes unusual line breaks in the
XML document passed in the POST body. Since stdin is in text mode by default,
those line breaks are modified and one char is taken out on each line, resulting
in the two missing chars in my test case.

Setting stdin to binary mode does the trick.

[fwarmerdam]

Daniel, 

I just made a similar change in 4.9 recently.  How/where do you do yours?
My change was to add msIO_needBinaryStdin() in mapio.c, and then call it
in the post reading code in cgitutils.c

[dmorissette]

My fix is the same as yours. I wish I had found bug 1768 before wasting time on
this. I did a search before starting and never found the bug.

*** This bug has been marked as a duplicate of 1768 ***