Thanks Even, I'll give that a go (the bisect worked well for another issue a 
few months ago). 

I presume the zipping issue is more likely to be in the MapServer codebase than 
in GDAL?
The GISInternals did switch from GDAL 2.4.4 to GDAL 3.3.3 from the 7.4.3 to 
7.6.4 branches.

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. 

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Fri, Nov 19, 2021, at 2:07 PM, Even Rouault wrote:
> 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.
> 
> Le 19/11/2021 à 09:43, Seth G a écrit :
>> Possibly unrelated but I ran into a similar issue exporting WFS to zipped 
>> shapefiles.
>> 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. 
>> 
>> 7-zip reports "Headers Error Unconfirmed start of archive"
>> 
>> The same command is used for both versions:
>> 
>> mapserv -nh 
>> "QUERY_STRING=map=my.map&service=WFS&REQUEST=GetFeature&TYPENAME=LayerName&version=2.0.0&outputformat=shapezip&srsName=EPSG:3857"
>>  > output.zip
>> 
>> I had a look with a hex editor but the start of the working and corrupt zips 
>> seem identical. 
>> 
>> On the other hand all PNGs / WMS services are fine. 
>> 
>> Seth
>> 
>> 
>> --
>> web:http://geographika.co.uk
>> twitter: @geographika
>> 
>> 
>> On Thu, Nov 18, 2021, at 3:53 PM, Steve Lime wrote:
>>> 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.
>>> 
>>> What do you get for output if you use mapserv.exe at the command line? So 
>>> something like:
>>> 
>>>   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
>>> 
>>> 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?
>>> 
>>> --Steve
>>> 
>>> On Wed, Nov 17, 2021 at 4:57 PM John Huotari via MapServer-users 
>>> <mapserver-users@lists.osgeo.org> wrote:
>>>> 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.
>>>>  
>>>> The good headers from 7.6.1 look like this
>>>>  
>>>> 89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52
>>>>  
>>>> and the corrupted ones from 7.6.4 look like this
>>>>  
>>>> 89 50 4e 47 0d 0d 0a 1a 0d 0a 00 00 00 0d 49 48 44 52
>>>>  
>>>> 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?
>>>>  
>>>> 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
>>>>  
>>>> 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
>>>>  
>>>> 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.
>>>> 
>>>> ******************* PLEASE NOTE *******************
>>>> 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.
>>>> _______________________________________________
>>>> MapServer-users mailing list
>>>> MapServer-users@lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>> _______________________________________________
>>> MapServer-users mailing list
>>> MapServer-users@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>> 
>> 
>> 
>> _______________________________________________
>> MapServer-users mailing list
>> MapServer-users@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> _______________________________________________
> MapServer-users mailing list
> MapServer-users@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
> 
_______________________________________________
MapServer-users mailing list
MapServer-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users

Reply via email to