Opened 14 years ago

Last modified 8 years ago

#1025 new defect doesn't always process WMS server responses (errors)

Reported by: marisn Owned by: grass-dev@…
Priority: normal Milestone: 6.4.6
Component: Raster Version: svn-develbranch6
Keywords: Cc:
CPU: Unspecified Platform: Unspecified


Current implementation is simply downloading data and not performing any kind of response parsing. If some WMS parameters are wrong, still will download and process error messages as if they where normal server responses. There's no use for few thousands of XML files with content i.e. "Output format not supported", also any processing of such "GeoTIFFs" will fail.

Change History (6)

comment:1 by hamish, 14 years ago

Keywords: added

actually it does check, it's just not very good at it. Also server response can come in many many forms so it is hard to check for with confidence.

have a look in the script for the lines just after:

# check for error like 'Service Exception Report'


in reply to:  1 ; comment:2 by marisn, 14 years ago

Replying to hamish:

Also server response can come in many many forms so it is hard to check for with confidence.

It's not that hard to force error messages to be returned as XML, as it is by default [1]. Current approach shomehow fails to detect XML error messages with .tiff name. Also it's not wise to get thousands of equal error messages.

  1. WMS 1.3.0 spec:
    The optional EXCEPTIONS parameter is defined in 6.9.4. The default value is 
    “XML” if this parameter is absent from the request.

in reply to:  2 comment:3 by hamish, 14 years ago

Summary: doesn't process WMS server responses (errors) doesn't always process WMS server responses (errors)

Replying to marisn:

  1. WMS 1.3.0 spec:

yeah, now if only we could get the servers to always follow the spec... :-/

fwiw the XML checking logic works for me on multiple versions of debian.

what does this say for you:

file -b really_a_xml.tif


file is not highly portable, better ways to test it welcome.


comment:4 by martinl, 11 years ago

Recently, has been completely rewritten. Is this issue still valid?

comment:5 by hamish, 11 years ago


Is this issue still valid?

it's still relevant to the shell script version; re-targeting milestone. I would not be surprised if the python version in trunk suffers from the same problem though, as it is to do with funny arbitrary/out-of-spec output from the server, which needs to be tested & approved as real image data by whichever grass module which makes the request.


comment:6 by neteler, 8 years ago

Note: See TracTickets for help on using tickets.