Opened 12 years ago

Last modified 6 years ago

#1025 new defect

r.in.wms 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: r.in.wms Cc:
CPU: Unspecified Platform: Unspecified

Description

Current r.in.wms implementation is simply downloading data and not performing any kind of response parsing. If some WMS parameters are wrong, r.in.wms 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, 12 years ago

Keywords: r.in.wms 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 r.in.wms script for the lines just after:

# check for error like 'Service Exception Report'

Hamish

in reply to:  1 ; comment:2 by marisn, 12 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:
    7.3.3.11
    EXCEPTIONS
    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, 12 years ago

Summary: r.in.wms doesn't process WMS server responses (errors)r.in.wms 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.

Hamish

comment:4 by martinl, 9 years ago

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

comment:5 by hamish, 9 years ago

Milestone: 7.0.06.4.4

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.

Hamish

comment:6 by neteler, 6 years ago

Milestone: 6.4.46.4.6
Note: See TracTickets for help on using tickets.