Specification - RETS

S ECTION
0MESSAGE FORMAT
CHAPTER
RETS uses HTTP version 1.1 [2] for sending messages between clients and servers. It
defines three additional HTTP headers, and some RETS transactions constrain the values
of certain headers defined by HTTP 1.1 and/or make certain headers designated as
optional in HTTP 1.1 mandatory when used for RETS. In addition, RETS requests use
HTML 4.01 [16] form encoding to encapsulate request parameters. In addition, a
compliant RETS client MUST implement cookie handling as specified in RFC 2109 [15].
The information below summarizes some of the requirements of HTTP 1.1 and
HTML 4.01 for ease of reference. However, in all cases, the underlying standards are the
normative references for message formats.
3.1 General Message Format
3.1.1 RETS HTTP/1.1 Encapsulation
3.1.2 Request Arguments
RETS messages are encapsulated as the bodies of HTTP/1.1 requests and responses. The
request body may be null, depending on the request. The response body is never null
Note that, per RFC 2822, keywords in header key-value pairs are not case-sensitive. The
values, however, may be case-sensitive depending on context.
RETS requests are HTML 4.01-compliant form submissions, following all of the
specifications in the HTML 4.01 recommendation. Note that the HTML 4.01 specification
provides that:
• Key names in key/value pairs are not case-sensitive.
• Both key names and key values MUST be encoded as specified in HTML 4.01 section
17.13.4, with + characters replacing spaces, and then reserved characters being
escaped per RFC 2396 [13], unless the client uses a content-type of multipart/formdata.
Version 1.7.2 3-1