46
Copyright © 2010 Open Geospatial Consortium, Inc.
We assume most specific OWSs will need to specify additional allowed exceptionCode values. In addition to the standard exceptionCode values specified in each
Implementation Specification, each server implementation is allowed to specify additional exceptionCode values and their meanings, for each implemented operation.
These additional exceptionCode values and their meanings should be clearly documented.
Because a client may not always know what set of exceptionCode values are being used by a server, all clients should be coded to allow exceptionCode values that it does not
recognize.
8.4 ―locator‖ parameter values
Each Implementation Specification shall also specify the expected contents of the ―locator‖ parameter value for each allowed exceptionCode, as needed for each operation
specified for that OWS. Inclusion of the ―locator‖ parameter in an Exception element shall be optional, but is recommended whenever useful information is available.
The standard contents of the ―locator‖ parameter for each exceptionCode should be as specified in the right column of Table 27. As shown for several exceptionCodes, the
―locator‖ parameter should be omitted when no appropriate value is defined.
EXAMPLE When the operation request includes values of a handle parameter, the locator
parameter for some specified exceptionCodes should be the relevant value of the handle parameter.
8.5 Exception report XML encoding
Each Exception Report shall be encoded in XML as specified by the attached owsExceptionReport.xsd file.
An example of an Exception Report encoded in XML is:
?xml version=1.0 encoding=UTF-8? ExceptionReport xmlns=http:www.opengis.netows2.0
xmlns:xsi=http:www.w3.org2001XMLSchema-instance xsi:schemaLocation=http:www.opengis.netows2.0
owsExceptionReport.xsd version=1.0.0 xml:lang=en
-- Simple example. Primary editor: Arliss Whiteside. Last updated 20041013. --
Exception exceptionCode=MissingParameterValue locator=service Exception exceptionCode=InvalidParameterValue locator=version
ExceptionReport
8.6 HTTP STATUS codes for OGC Exceptions
When an OWS instance would respond with an ExceptionReport and when the report is transmitted via HTTP the OWS instance shall set the HTTP response’s status code to the
corresponding value for the given exceptionCode values, as shown in Table 28. When the ExceptionReport contains more than one Exception then the HTTP status code value
shall be based upon the exceptionCode of the first Exception in the ExceptionReport.
Copyright © 2010 Open Geospatial Consortium, Inc.
47 OWS specifications specifying additional exceptionCode values shall provide a
corresponding HTTP status code value for every new exceptionCode. A comprehensive list of HTTP status codes is available in clause 10, Status Code Definitions, of [IETF
RFC 2616]. A more accessible list is available at
http:www.w3.orgProtocolsrfc2616rfc2616-sec10.html .
Table 28 — Standard exception codes and meanings
exceptionCode value HTTP Status Code
Code Message
OperationNotSupported
501 Not Implemented
MissingParameterValue 400
Bad request InvalidParameterValue
400 Bad request
VersionNegotiationFailed 400
Bad request InvalidUpdateSequence
400 Bad request
OptionNotSupported 501
Not Implemented NoApplicableCode
3xx, 4xx, 5xx Internal Server Error
An example showing an HTTP response with the status code 400 and the body containing an ExceptionReport is:
HTTP1.1 400 Bad Request Date: Thu, 4 Sep 2008 06:20:15 GMT
Content-Type: applicationxml Content-Language: en
Content-Length: 493 ?xml version=1.0 encoding=UTF-8?
ExceptionReport xmlns=http:www.opengis.netows2.0 xmlns:xsi=http:www.w3.org2001XMLSchema-instance
xsi:schemaLocation=http:www.opengis.netows2.0 owsExceptionReport.xsd
version=1.0.0 xml:lang=en Exception exceptionCode=MissingParameterValue
locator=service Exception exceptionCode=InvalidParameterValue
locator=version ExceptionReport
8.7 Exception report SOAP encoding
