Hi,
looking into the WCS 2.0 CITE tests failures we discovered that the CITE
test expects a OWS 2.0 service exception when making invalid requests, whilst
sometimes GeoServer returns a OWS 1.0 one.
The “sometimes” happens when GeoServer does not have any way to determine
the service in the first place, such as:
…?request=GetCapabilities&service=ABC
Now, imho the WCS 2.0 CITE tests is completely broken in this respect, because
when hitting a multi-service server that has several services implementing different
OWS specifications one cannot expect a specific service exception type back:
it’s completely arbitrary.
However, at the same time, GeoServer is being arbitrary too, by always sending
back a OWS 1.0 exception.
Imho the administrator should be allowed to choose the default service exception
handler, its OWS version in particular. Still arbitrary, but at least an administrator
with a good reason can set the default OWS version.
I see this as a drop down in the “global” configuration page, “default exception level”
→ “ows 1.0”, “ows 1.1”, “ows 2.0”
With the above at the very least the WCS 2.0 can be configured to pass the CITE
tests anyways, in case OGC decides that no, we really have to throw exceptions
at that level
Opinions?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Would that only be a concern when version is not specified in the
request? Since version is (afaik) always a required request parameter
(except for getcaps), would it make sense that if no version has been
specified as a request parameter, geoserver chooses the highest ows
version exception handler?
On Thu, Dec 13, 2012 at 2:55 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
Hi,
looking into the WCS 2.0 CITE tests failures we discovered that the CITE
test expects a OWS 2.0 service exception when making invalid requests,
whilst
sometimes GeoServer returns a OWS 1.0 one.
The "sometimes" happens when GeoServer does not have any way to determine
the service in the first place, such as:
...?request=GetCapabilities&service=ABC
Now, imho the WCS 2.0 CITE tests is completely broken in this respect,
because
when hitting a multi-service server that has several services implementing
different
OWS specifications one cannot expect a specific service exception type back:
it's completely arbitrary.
However, at the same time, GeoServer is being arbitrary too, by always
sending
back a OWS 1.0 exception.
Imho the administrator should be allowed to choose the default service
exception
handler, its OWS version in particular. Still arbitrary, but at least an
administrator
with a good reason can set the default OWS version.
I see this as a drop down in the "global" configuration page, "default
exception level"
-> "ows 1.0", "ows 1.1", "ows 2.0"
With the above at the very least the WCS 2.0 can be configured to pass the
CITE
tests anyways, in case OGC decides that no, we really have to throw
exceptions
at that level
Opinions?
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Not sure if this one went anywhere but here are my thoughts.
I like both ideas. For the first (explicitly setting the ows version) what about the hypothetical case of a ogc service for which there is no version that corresponds to ows 1.0. Then it would probably not make sense to return the 1.0 error document in the ambiguous version case.
Gabriels idea is certainly simpler and more consistent with our general version negotiation strategy of the highest wins when its ambiguous.
The configurable idea might make more sense if it were something like configuring the default version for a service period, overriding the default behaviour of returning the highest version. This would be a pretty nice feature for people upgrading to a version that adds a new service version.
$0.02
On Fri, Dec 14, 2012 at 2:32 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
Would that only be a concern when version is not specified in the
request? Since version is (afaik) always a required request parameter
(except for getcaps), would it make sense that if no version has been
specified as a request parameter, geoserver chooses the highest ows
version exception handler?
On Thu, Dec 13, 2012 at 2:55 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
Hi,
looking into the WCS 2.0 CITE tests failures we discovered that the CITE
test expects a OWS 2.0 service exception when making invalid requests,
whilst
sometimes GeoServer returns a OWS 1.0 one.
The “sometimes” happens when GeoServer does not have any way to determine
the service in the first place, such as:
…?request=GetCapabilities&service=ABC
Now, imho the WCS 2.0 CITE tests is completely broken in this respect,
because
when hitting a multi-service server that has several services implementing
different
OWS specifications one cannot expect a specific service exception type back:
it’s completely arbitrary.
However, at the same time, GeoServer is being arbitrary too, by always
sending
back a OWS 1.0 exception.
Imho the administrator should be allowed to choose the default service
exception
handler, its OWS version in particular. Still arbitrary, but at least an
administrator
with a good reason can set the default OWS version.
I see this as a drop down in the “global” configuration page, “default
exception level”
→ “ows 1.0”, “ows 1.1”, “ows 2.0”
With the above at the very least the WCS 2.0 can be configured to pass the
CITE
tests anyways, in case OGC decides that no, we really have to throw
exceptions
at that level
Opinions?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Fri, Jan 4, 2013 at 7:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Not sure if this one went anywhere but here are my thoughts.
I like both ideas. For the first (explicitly setting the ows version) what about the hypothetical case of a ogc service for which there is no version that corresponds to ows 1.0. Then it would probably not make sense to return the 1.0 error document in the ambiguous version case.
Gabriels idea is certainly simpler and more consistent with our general version negotiation strategy of the highest wins when its ambiguous.
The configurable idea might make more sense if it were something like configuring the default version for a service period, overriding the default behaviour of returning the highest version. This would be a pretty nice feature for people upgrading to a version that adds a new service version.
Yep, the highest wins seems reasonable but… comes at a cost implementation wise and it’s not always straightforward.
For example, we’d have to modify all ServiceInfo to advertise which version of OWS they are based onto (there is no
relationship between a service version and the OWS version it implements).
Moreover, I believe that WMS 1.1 (or was it 1.0?) was not based on any OWS version? I believe we have a custom
handler for it.
The per service configuration of excemptions makes sense too, but the service requests coming in from
the WCS 2.0 CITE tests ask for service=GOO (and expect a OWS 2.0 exception),
at which point a per service strategy makes no sense either.
That’s why I was proposing a simple global default instead, which is what we have today, but would at
least be configurable instead of hard coded to OWS 1.0
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On Fri, Jan 4, 2013 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 4, 2013 at 7:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Not sure if this one went anywhere but here are my thoughts.
I like both ideas. For the first (explicitly setting the ows version) what about the hypothetical case of a ogc service for which there is no version that corresponds to ows 1.0. Then it would probably not make sense to return the 1.0 error document in the ambiguous version case.
Gabriels idea is certainly simpler and more consistent with our general version negotiation strategy of the highest wins when its ambiguous.
The configurable idea might make more sense if it were something like configuring the default version for a service period, overriding the default behaviour of returning the highest version. This would be a pretty nice feature for people upgrading to a version that adds a new service version.
Yep, the highest wins seems reasonable but… comes at a cost implementation wise and it’s not always straightforward.
For example, we’d have to modify all ServiceInfo to advertise which version of OWS they are based onto (there is no
relationship between a service version and the OWS version it implements).
Moreover, I believe that WMS 1.1 (or was it 1.0?) was not based on any OWS version? I believe we have a custom
handler for it.
The per service configuration of excemptions makes sense too, but the service requests coming in from
the WCS 2.0 CITE tests ask for service=GOO (and expect a OWS 2.0 exception),
at which point a per service strategy makes no sense either.
That’s why I was proposing a simple global default instead, which is what we have today, but would at
least be configurable instead of hard coded to OWS 1.0
Gotcha. Works for me.
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.