Opened 15 years ago
Last modified 9 years ago
#1025 new defect
r.in.wms doesn't always process WMS server responses (errors)
Reported by: | marisn | Owned by: | |
---|---|---|---|
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)
follow-up: 2 comment:1 by , 15 years ago
Keywords: | r.in.wms added |
---|
follow-up: 3 comment:2 by , 15 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.
- 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.
comment:3 by , 15 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:
- 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 , 12 years ago
Recently, r.in.wms
has been completely rewritten. Is this issue still valid?
comment:5 by , 12 years ago
Milestone: | 7.0.0 → 6.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 , 9 years ago
Milestone: | 6.4.4 → 6.4.6 |
---|
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:
Hamish