<!DOCTYPE html><html><head><title></title><style type="text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Yes apologies John for hijacking the thread, I thought it could be related to your issue but looking less and less likely.<br></div><div>Steve's suggestion to use the commandline mapserv -nh "QUERY..." approach should rule out a few more issues. <br></div><div><br></div><div>Even - the same zip cannot be opened on Linux either (using Ark and unzip): "9487 extra bytes at begging or within zipfile". <br></div><div>The GDAL within the build (3.3.3) creates a zip of the WFS just fine for the same layer/WFS service using ogr2ogr:<br></div><div><br></div><div>ogr2ogr -f "ESRI Shapefile" "H:/Temp/test.shp.zip" WFS:"<a href="https://plmonaghandev.compass.ie/mapserver/?service=WFS&REQUEST=GetFeature&version=2.0.0">https://server/mapserver/?service=WFS&REQUEST=GetFeature&version=2.0.0</a>" LayerName -overwrite -skipfailures<br></div><div><br></div><div>GDAL 2.4.4 doesn't create zips so it must be MapServer doing the zipping in this version at least?<br></div><div>I'm guessing this points to a MapServer issue, so I'll carry on debugging.<br></div><div><br></div><div>Seth<br></div><div><br></div><div id="sig62266145"><div class="signature">--<br></div><div class="signature">web:http://geographika.co.uk<br></div><div class="signature">twitter: @geographika<br></div></div><div><br></div><div><br></div><div>On Fri, Nov 19, 2021, at 4:11 PM, Even Rouault wrote:<br></div><blockquote type="cite" id="qt" style=""><p>Ah, GDAL also changed... Zipping is done by GDAL, so could be a
      GDAL related change (there were adjustments in the past regarding
      ZIP64 that could result in some bytes being different). Did you
      try opening the zip with another utility (like 'unzip' on Linux) ?<br></p><p>This might be then a completely different issue than the one
      reported by John.<br></p><div class="qt-moz-cite-prefix">Le 19/11/2021 à 16:01, Seth G a écrit :<br></div><blockquote type="cite" cite="mid:12b6ad09-e661-4eb1-a128-fa4082219923@www.fastmail.com"><div>Thanks Even, I'll give that a go (the bisect worked well for
        another issue a few months ago). <br></div><div><br></div><div>I presume the zipping issue is more likely to be in the
        MapServer codebase than in GDAL?<br></div><div>The GISInternals did switch from GDAL 2.4.4 to GDAL 3.3.3
        from the 7.4.3 to 7.6.4 branches.<br></div><div><br></div><div>The zip exports work fine over a web browser rather than
        command line which is strange. Maybe its related to
        modifications to the -nh switch. <br></div><div><br></div><div>Seth<br></div><div><br></div><div id="qt-sig62266145"><div class="qt-signature">--<br></div><div class="qt-signature">web:<a class="qt-moz-txt-link-freetext" href="http://geographika.co.uk">http://geographika.co.uk</a><br></div><div class="qt-signature">twitter: @geographika<br></div></div><div><br></div><div><br></div><div>On Fri, Nov 19, 2021, at 2:07 PM, Even Rouault wrote:<br></div><blockquote type="cite" id="qt-qt" style=""><p>Could be a msIO_needBinaryStdout() missing somewhere. Seth,
          if you've the chance to run a git bisect session, that could
          probably give a strong hint of how to fix that.<br></p><div class="qt-qt-moz-cite-prefix">Le 19/11/2021 à 09:43, Seth G a
          écrit :<br></div><blockquote type="cite" cite="mid:6cfd4198-5052-4102-bb76-39fed57450ec@www.fastmail.com"><div>Possibly unrelated but I ran into a similar issue
            exporting WFS to zipped shapefiles.<br></div><div>Working fine in 7-4-3 but broken in 7-6-4 (and current
            master) - the zip files are corrupt, although they have an
            identical size. <br></div><div><br></div><div>7-zip reports "Headers Error Unconfirmed start of
            archive"<br></div><div><br></div><div>The same command is used for both versions:<br></div><div><br></div><div>mapserv -nh
"QUERY_STRING=map=my.map&service=WFS&REQUEST=GetFeature&TYPENAME=LayerName&version=2.0.0&outputformat=shapezip&srsName=EPSG:3857"
            > output.zip<br></div><div><br></div><div>I had a look with a hex editor but the start of the
            working and corrupt zips seem identical. <br></div><div><br></div><div>On the other hand all PNGs / WMS services are fine. <br></div><div><br></div><div>Seth<br></div><div><br></div><div><br></div><div id="qt-qt-sig62266145"><div class="qt-qt-signature">--<br></div><div class="qt-qt-signature">web:<a class="qt-qt-moz-txt-link-freetext" href="http://geographika.co.uk">http://geographika.co.uk</a><br></div><div class="qt-qt-signature">twitter: @geographika<br></div></div><div><br></div><div><br></div><div>On Thu, Nov 18, 2021, at 3:53 PM, Steve Lime wrote:<br></div><blockquote type="cite" id="qt-qt-qt" style=""><div dir="ltr"><div>Hmmm... I've not run into or heard of this before
                although I'm not a windows user. I did a quick sanity
                check with a mapfile here and the latest 7.4 and 7.6
                versions. While not exactly the same setup you have in
                terms of versions, they produce the exact same png
                image.<br></div><div><br></div><div>What do you get for output if you use mapserv.exe at
                the command line? So something like:<br></div><div><br></div><div><div>  mapserv.exe -nh "QUERY_STRING=
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"
                  > test.png<br></div><div><br></div><div>That would take PostMan and the web server out of
                  the picture. Is there any chance different versions of
                  libpng are being used? What are you using to manage
                  the tiles?<br></div></div><div><br></div><div>--Steve<br></div></div><div><br></div><div class="qt-qt-qt-gmail_quote"><div dir="ltr" class="qt-qt-qt-gmail_attr">On Wed, Nov 17,
                2021 at 4:57 PM John Huotari via MapServer-users <<a href="mailto:mapserver-users@lists.osgeo.org">mapserver-users@lists.osgeo.org</a>>
                wrote:<br></div><blockquote class="qt-qt-qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div lang="EN-US"><div class="qt-qt-qt-gmail-m_4804338606052070718WordSection1"><p class="qt-qt-qt-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.<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-MsoNormal">The good headers from
                      7.6.1 look like this<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-MsoNormal">89 50 4e 47 0d 0a 1a 0a 
                      00 00 00 0d 49 48 44 52<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-MsoNormal">and the corrupted ones
                      from 7.6.4 look like this<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-MsoNormal">89 50 4e 47 0d 0d 0a 1a
                      0d 0a 00 00 00 0d 49 48 44 52<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-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?<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-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<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-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<br></p><p class="qt-qt-qt-MsoNormal"> <br></p><p class="qt-qt-qt-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.<br></p></div><div><br></div><div>******************* PLEASE NOTE
                    *******************<br></div><div>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.<br></div></div><div>_______________________________________________<br></div><div>MapServer-users mailing list<br></div><div><a href="mailto:MapServer-users@lists.osgeo.org" target="_blank">MapServer-users@lists.osgeo.org</a><br></div><div><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br></div></blockquote></div><div>_______________________________________________<br></div><div>MapServer-users mailing list<br></div><div><a href="mailto:MapServer-users@lists.osgeo.org">MapServer-users@lists.osgeo.org</a><br></div><div><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br></div><div><br></div></blockquote><div><br></div><div><br></div><pre class="qt-qt-moz-quote-pre">_______________________________________________
MapServer-users mailing list
<a class="qt-qt-moz-txt-link-abbreviated" href="mailto:MapServer-users@lists.osgeo.org">MapServer-users@lists.osgeo.org</a>
<a class="qt-qt-moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/mapserver-users">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a>

<br></pre></blockquote><pre class="qt-qt-moz-signature" cols="72">-- 
<a class="qt-qt-moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.
<br></pre><div>_______________________________________________<br></div><div>MapServer-users mailing list<br></div><div><a href="mailto:MapServer-users@lists.osgeo.org">MapServer-users@lists.osgeo.org</a><br></div><div><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br></div><div><br></div></blockquote><div><br></div></blockquote><pre class="qt-moz-signature" cols="72">-- 
<a class="qt-moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.<br></pre></blockquote><div><br></div></body></html>