[GRASS-dev] [GRASS GIS] #1025: r.in.wms doesn't process WMS server responses (errors)

#1025: r.in.wms doesn't process WMS server responses (errors)
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-develbranch6
Keywords: | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1025&gt;
GRASS GIS <http://grass.osgeo.org>

#1025: r.in.wms doesn't process WMS server responses (errors)
--------------------------+-------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.in.wms
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by hamish):

  * keywords: => r.in.wms

Comment:

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1025#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#1025: r.in.wms doesn't process WMS server responses (errors)
--------------------------+-------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.in.wms
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by marisn):

Replying to [comment:1 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.
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1025#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#1025: r.in.wms doesn't always process WMS server responses (errors)
--------------------------+-------------------------------------------------
  Reporter: marisn | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.in.wms
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by hamish):

  * summary: r.in.wms doesn't process WMS server responses (errors) =>
              r.in.wms doesn't always process WMS server
              responses (errors)

Comment:

Replying to [comment:2 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1025#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#1025: r.in.wms doesn't always process WMS server responses (errors)
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-develbranch6
Keywords: r.in.wms | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by martinl):

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1025#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

#1025: r.in.wms doesn't always process WMS server responses (errors)
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Raster | Version: svn-develbranch6
Keywords: r.in.wms | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by hamish):

  * milestone: 7.0.0 => 6.4.4

Comment:

> 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1025#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>