11.7 HTTP responses
Upon receiving a valid operation request, the service shall send a response corresponding exactly to the request as detailed in the Implementation Specification, or send an
exception report if unable to respond correctly. Only in the case of Version Negotiation Subclause 7.3.2 may the server return a differing result. Upon receiving an invalid
request, the service shall issue an exception report as specified in Clause 8.
NOTE 1 As a practical matter, a client should be prepared to receive either a valid result, or nothing, or
any other result. This is because the client may have formed a non-conforming request that inadvertently triggered a reply by something other than an OWS, because the server may be non-conforming, etc.
A server may send an HTTP Redirect message using HTTP response codes as defined in [IETF RFC 2616] to an absolute URL that is different from the valid request URL that
was sent by the client. HTTP Redirect causes the client to issue a new HTTP request for the new URL. Several redirects could in theory occur. Practically speaking, the redirect
sequence ends when the server responds with an operation response. The final response shall be an OWS operation response that corresponds exactly to the original operation
request or an exception report.
Response objects shall be accompanied by the appropriate Multipurpose Internet Mail Extensions MIME type [IETF RFC 2045] for that object. A list of MIME types in
common use on the internet is maintained by the Internet Assigned Numbers Authority [IANA]. Allowable types for operation responses and exception reports are discussed
below.
The basic structure of a MIME type is a string of the form typesubtype. MIME allows additional parameters in a string of the form typesubtype; param1=value1;
param2=value2. A server may include parameterized MIME types in its list of supported output formats. In addition to any parameterized variants, the server should offer the
basic un-parameterized version of the format.
Response objects should be accompanied by other HTTP entity headers as appropriate and to the extent possible. In particular, the Expires and Last-Modified headers provide
important information for caching. Content-Length may be used by clients to know when data transmission is complete and to efficiently allocate space for results, and Content-
Encoding or Content-Transfer-Encoding may be necessary for proper interpretation of the results.
When returning a large XML document, some form of data compression should be supported. Client-server communication transfer speeds will be considerably faster if the
document is compressed.
NOTE 2 The standard HTTP way of negotiating compression using gzip is fully defined in IETF RFC
2616, see Sections 3.5, 14.3, and 14.11. Briefly, if the client is able to support gzip compression, it may include the MIME header Accept-Encodings: gzip in its operation request. If the server sees this MIME
header in the request and supports this compression, it may compress its operation response using gzip, flagging it as compressed by including the MIME header Content-Encoding: gzip. If the client sees this
MIME header in the operation response, it shall decompress the response before parsing it.”
Copyright © 2006 Open Geospatial Consortium, Inc. All Rights Reserved.
81
12 Guidance for OWS Implementation Specifications
12.1 General guidance
Kategori