<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">I’m attempting to upgrade from MapServer 7.6.1 to 7.6.4 via compiled packages obtained from GISInternals. I’m running it on Windows/IIS and whereas 7.6.1 was generating .PNG tiles perfectly for me, after upgrading to 7.6.4, the .PNGs being
created appear to be corrupt. I can replace the 7.6.4 exe and dlls with 7.6.1 versions and the PNG images generate fine again, so while there are quite a few places that could introduce an issue, with the exception of a change to MapServer everything would
be identical in my stack between having the issue in 7.6.4 and not in 7.6.1.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The good headers from 7.6.1 look like this<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">and the corrupted ones from 7.6.4 look like this<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">89 50 4e 47 0d 0d 0a 1a 0d 0a 00 00 00 0d 49 48 44 52<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It appears that the 0a values from the valid header are being converted to 0d 0a. I might be wrong here, but it appears to me that something is interpreting the 0a as a line feed and given the code is running on Windows, is converting
that LF into a CR LF. The replacement doesn’t seem to be limited to the file header as I see the 7.6.4 version of the file is slightly larger (18,571 bytes instead of 18,407 bytes) and in spot checking, I’ve verified some additional 0d’s exist precede 0a
within the data blocks of the .PNG. Has anyone experienced anything like this or know of any fixes?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">PNG Images produced on the server with shp2img are just fine, it’s only images produced by making a WMS request to mapserv.exe that have the issue. An example WMS request would be<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">https://<Server Name Removed>/mapserv.exe?map=dynamic\5708d96b-c606-4c35-95e7-085fedc1dcce.map&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=MAP&TILED=true&WIDTH=512&HEIGHT=512&CRS=EPSG%3A3857&STYLES=&BBOX=-10877294.873093722%2C5536486.832751887%2C-10876071.880641159%2C5537709.82520445<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Maybe I’m completely misdiagnosing the problem as these PNG image files just show up as corrupted within a browser – for example FireFox reports “The image <full URL here> cannot be displayed because it contains errors.” The way I obtained
the actual .PNG images to view in a binary editor was to use PostMan and save the body of the results. Perhaps PostMan introduced the extra bytes when saving an unrecognizable format file to disk whereas it did not when saving a file it recognized as a valid
PNG. I can’t find anything different between the valid and invalid files beyond the extra 0d’s that have been added though, so I don’t think PostMan or anything else in the chain introduced them.<o:p></o:p></p>
</div>
<br>
******************* PLEASE NOTE *******************<br>
This message, along with any attachments, is for the designated recipient(s) only and may contain privileged, proprietary, or otherwise confidential information. If this message has reached you in error, kindly destroy it without review and notify the sender
immediately. Any other use of such misdirected e-mail by you is prohibited. Where allowed by local law, electronic communications with Zurich and its affiliates, including e-mail and instant messaging (including content), may be scanned for the purposes of
information security and assessment of internal compliance with company policy.
</body>
</html>