Overview Message headers The HTTP protocol

10 HTTP protocol binding Catalogue Services for the Web, CSW

10.1 Architectural principles

The purpose of this clause is to describe the request and response messages that are common to all web-based catalogue services. The basic message exchange pattern is illustrated in . Figure 28 — Catalogue service web The interaction between a client and a server is accomplished using a standard request- response model of the HTTP protocol. That is, a client sends a request to a server using HTTP, and expects to receive a response to the request or an exception message. Request and response messages are encoded as keyword-value pairs within a request URI or using an XML entity-body. Requests may also be embedded in a messaging framework such as SOAP.

10.2 The HTTP protocol

10.2.1 Overview

The Hypertext Transfer Protocol HTTP is a generic, stateless, application-level protocol that is widely used to exchange information on the web. The HTTP1.1 specification is published by the Internet Engineering Task Force IETF as RFC 2616: http:www.ietf.orgrfcrfc2616 . The http URI scheme is used to locate network resources using the HTTP protocol; consult Section 3.2 of RFC 2616 and RFC 2396 for details. The general syntax of the scheme is summarised below for convenience: http_URL = http: host [ : port ] [ abs_path [ ? query ]] Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 115 HTTP messages have a simple line-oriented structure. The three basic parts of a message are summarised in Table 51 RFC 2616, 4.1: Table 51 — HTTP message elements Start line Indicates what to do for a request or what happened for a response. Header fields Zero or more header fields, each consisting of a name and a value separated by a colon :. Four categories of headers provide metainformation about the message: general, request, response, and entity. The headers part ends with a blank line. Body An optional body containing the message content that conforms to some Internet media type. Note that URIs are generally case-sensitive except for the scheme and host names; furthermore, if the port number is not specified it is equivalent to the default TCP port number 80. As noted in Section 3 of RFC 2396, certain special characters are reserved within various URI components; if the data within a URI component conflicts with the reserved purpose it shall be escaped before forming the URI. This subclause clarifies some aspects of HTTP usage for catalogue application profiles that employ the protocol to exchange request and response messages. In many cases this means turning a SHOULD level requirement into a SHALL level requirement; what results is effectively an HTTP profile for OGC catalogue services.

10.2.2 Message headers

The standard headers are defined in Section 14 of RFC 2616. Some of these are of particular significance to catalogue operations. Any HTTP1.1 message containing an entity-body shall include a Content-Type header field defining the media type of that body RFC 2616, 7.2.1; the charset parameter shall also be specified for text. EXAMPLES 1 Content-Type: applicationxml; charset=utf-8 Content-Type: applicationoctet-stream Content-Type: multipartrelated; boundary=part-boundary; start=urn:uuid:e3fec7a9-cc5d-45ba-87a5-8a2a27f6fb5b type=applicationxml A user agent may use the Accept request header to declare a set of preferred Internet media types for the response. The IANA registry of media types is available online: http:www.iana.orgassignmentsmedia-types . EXAMPLES 2 Accept: applicationxml Accept: applicationxhtml+xml, texthtml; q=0.5 Implementers should be mindful that the function of some request parameters e.g. outputFormat overlaps the functionality of some of the HTTP message headers e.g., Accept. When a request to a CSW service includes both a request parameter e.g., 116 Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. outputFormat and a message header that perform similar functions e.g., Accept, the server shall use the value of the request parameter e.g., outputFormat to process the request. When the request parameter is not specified, the value of the HTTP message header shall be used. If the value of the request parameter and the HTTP message header disagree, server shall raise an exception. If neither is specified, the default value of the request parameter shall be used if one is specified; otherwise the server shall raise an exception as specified in Subclause 10.3.7.

10.2.3 Content encoding