specs/http-client-2/index.html

<!DOCTYPE html>
<html>
  <head>
    <title>HTTP Client Module 2.0</title>
    <meta charset='utf-8'/>
    <script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus: "base",

          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName: "http-client2",

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          subtitle: "An EXPath Project",

          // if you wish the publication date to be other than today, set this
          // publishDate: "2009-08-06",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          // previousPublishDate: "1977-03-15",
          // previousMaturity: "WD",

          // if there a publicly available Editor's Draft, this is the link
          // edDraftURI: "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
          edDraftURI: "http://expath.github.io/expath-cg/specs/http-client2/",

          // if this is a LCWD, uncomment and set the end of its review period
          // lcEnd: "2009-08-05",

          // editors, add as many as you like
          // only "name" is required
          editors: [
              { name: "Christian Grün", url: "http://christian-gruen.de/",
                company: "BaseX GmbH", companyURL: "http://basex.org/" },
              { name: "Adam Retter", url: "http://adamretter.org.uk/",
                company: "Evolved Binary", companyURL: "http://evolvedbinary.com/" }
          ],

          // authors, add as many as you like.
          // This is optional, uncomment if you have authors as well as editors.
          // only "name" is required. Same format as editors.
          //authors: [
          //],

          // name of the WG
          wg: "EXPath Community Group",

          // URI of the public WG page
          wgURI: "https://www.w3.org/community/expath/",

          // name (without the @w3c.org) of the public mailing to which comments are due
          //wgPublicList: "exquery-restxq",

          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI: "",

          // If specified, defines an array of alternate formats in which document is available
          // (e.g., XML, Postscript). The format of the array is:
          // alternateFormats:

          doRDFa: "1.1",
      };
    </script>
  </head>
  <body>
    <!--<section id="sotd"/>
    </section>-->

    <section id='abstract'>
      <p>
        This specification provides an HTTP client interface for XML languages.
        It defines several extension functions to perform HTTP requests.
        It is backward-compliant with version 1.0 of the
        <a href='http://expath.org/spec/http-client'>HTTP Client Module</a>
        and has been designed to be compatible with [[!XQUERY-31]] and [[!XPATH-31]].
      </p>
    </section>

    <section id='introduction'>
      <h2>Introduction</h2>
      <p>
        The <a href='http://expath.org/spec/http-client'>HTTP Client Module</a> provides an HTTP
        client interface for XML languages. Version 2.0 provides the following features:
      </p>
      <ul>
        <li>Convenience functions are provided to simplify basic requests.</li>
        <li>Maps and arrays were added to [[!XPATH-31]]. The functions take advantage of the new
          data structures.</li>
        <li>In the initial specification, different ways exist to supply some of the arguments, such
          as the request URI or the payload. In the new functions, single locations are defined for
          all arguments.</li>
        <li>Single and multipart bodies are always passed on as items and never passed on as text
          nodes of an XML body element. This simplifies lazy evaluation and streaming of data in
          implementations.
        </li>
      </ul>

      <section>
        <h2>Namespaces and Prefixes</h2>
        <p>
          All functions and errors in this module are assigned to the
          <code>http://expath.org/ns/http-client</code> namespace. In this document, the
          <code>http</code> prefix is bound to this URI.
        </p>
      </section>
    </section>

    <section id='supported-http-versions'>
      <h2>Supported HTTP versions</h2>
      <p>Implementations of this module are expected to support HTTP 1.0 [[!rfc1945]],
        1.1 [[!rfc2616]], and 2.0 [[!rfc7540]]. Unless otherwise explicitly stated in this
        specification, client behaviour is expected to conform to the appropriate HTTP RFC.</p>
      <section id="http1-support">
        <h3>HTTP 1.0 Support</h3>
        <p>This module supports all features of HTTP 1.0. Although we do not provide explicit
          functions for the <code>LINK</code> and <code>UNLINK</code> HTTP methods, as in practice
          these methods do not appear to be widely used, they are still supported via the
          <a>http:send</a> function.
      </section>
      <section id="http2-support">
        <h3>HTTP/2 Support</h3>
        <p>We acknowledge that HTTP/2 support is currently in its infancy. We have attempted to
          design for a future version of this specification to extend control for HTTP/2 via.
          extension points such as <code>$options</code> and further arity functions. We await
          feedback from the users of the HTTP Client 2.0 spec, with regards to revisions for further
          support of HTTP/2 features.</p>
      </section>
    </section>

    <section id='functions'>
      <h2>Functions</h2>
      <p>
        The functions of this document have several things in common:
      </p>
      <ul>
        <li>All of them have been designed to send HTTP requests to a server, and to return the
          response to the client.</li>
        <li>The first parameter, <a>$uri</a>, contains the URI of the addressed server.</li>
        <li>The <code>$body</code> parameter is explained in
          <a href="#request-body" class="sectionRef"></a>.</li>
        <li>In <a href="#request-options" class="sectionRef"></a>, the supported
          <code>$options</code> are listed.</li>
        <li>In <a href="#response" class="sectionRef"></a>, the format of the returned result is
          described.</li>
      </ul>

      <p>
        The legacy function <code>http:send-request</code> is still available; it is explained in
        detail in the original <a href='http://expath.org/spec/http-client'>HTTP Client Module</a>.
      </p>

      <section>
        <h3>http:get</h3>
        <div class="exampleInner">
          <pre>
http:get($uri as xs:string) as map(xs:string, item())
http:get($uri as xs:string, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a GET request to the supplied <code>$uri</code> and returns the response as a map.
          Additional <code>$options</code> can be supplied.
        </p>
      </section>

      <section>
        <h3>http:post</h3>
        <div class="exampleInner">
          <pre>
http:post($uri as xs:string, $body as item()?) as map(xs:string, item())
http:post($uri as xs:string, $body as item()?, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a POST request with an optional <code>$body</code> to the supplied
          <code>$uri</code> and returns the response as a map. Additional <code>$options</code> can
          be supplied.
        </p>
      </section>

      <section>
        <h3>http:put</h3>
        <div class="exampleInner">
          <pre>
http:put($uri as xs:string, $body as item()?) as map(xs:string, item())
http:put($uri as xs:string, $body as item()?, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a PUT request with an optional <code>$body</code> to the supplied <code>$uri</code>
          and returns the response as a map. Additional <code>$options</code> can be supplied.
        </p>
      </section>

      <section>
        <h3>http:delete</h3>
        <div class="exampleInner">
          <pre>
http:delete($uri as xs:string) as map(xs:string, item())
http:delete($uri as xs:string, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a DELETE request to the supplied <code>$uri</code> and returns the response as a
          map. Additional <code>$options</code> can be supplied.
        </p>
      </section>

      <section>
        <h3>http:head</h3>
        <div class="exampleInner">
          <pre>
http:head($uri as xs:string) as map(xs:string, item())
http:head($uri as xs:string, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a HEAD request to the supplied <code>$uri</code> and returns the response as a map.
          Additional <code>$options</code> can be supplied.
        </p>
      </section>

      <section>
        <h3>http:options</h3>
        <div class="exampleInner">
          <pre>
http:options($uri as xs:string) as map(xs:string, item())
http:options($uri as xs:string, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends an OPTIONS request to the supplied <code>$uri</code> and returns the response as a
          map. Additional <code>$options</code> can be supplied.
        </p>
      </section>

      <section>
        <h3>http:trace</h3>
        <div class="exampleInner">
          <pre>
http:trace($uri as xs:string, $body as item()?) as map(xs:string, item())
http:trace($uri as xs:string, $body as item()?, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a TRACE request with an optional <code>$body</code> to the supplied <code>$uri</code>
          and returns the response as a map. Additional <code>$options</code> can be supplied.
        </p>
      </section>

      <section>
        <h3><dfn>http:send</dfn></h3>
        <div class="exampleInner">
          <pre>
http:send($uri as xs:string, $method as xs:string) as map(xs:string, item())
http:send($uri as xs:string, $method as xs:string, $body as item()?) as map(xs:string, item())
http:send($uri as xs:string, $method as xs:string, $body as item()?, $options as map(xs:string, item())) as map(xs:string, item())
</pre>
        </div>
        <p>
          Sends a custom HTTP request with the supplied <code>$method</code> and an optional
          <code>$body</code> to the specified <code>$uri</code> and returns the response as a map.
          Additional <code>$options</code> can be supplied. The <code>$method</code> should be
          specified accoding to the appropriate specification, for HTTP this means in upper-case
          characters.
        </p>
      </section>
    </section>

    <section id='request'>
      <h2>The Request</h2>
      <p>
        An HTTP request is made to a URI, and consists of a header section and an optional body section.
      </p>

      <section id="request-uri">
        <h3>The Request URI</h3>
        <p>The request URI is always specified in the <dfn>$uri</dfn> parameter to each function.
          The request URI MUST be a valid URI according to the RFC of the HTTP version that is
          being used for the request. If the URI is invalid, the error <a>http:invalid-uri</a>
          MUST be raised.</p>
      </section>

      <section id='request-options'>
        <h3>Request Options</h3>
        <p>
          The following options are available:
        </p>

        <div class="ednote" title="CG">
        </div>

        <dl>
          <dt><code>http-version</code> (<code>xs:string</code>)</dt>
          <dd>The HTTP Version to use for the request. Default: 1.1.
            Supported versions are <code>1.0</code>, <code>1.1</code>,
            and <code>2.0</code>.
          </dd>

          <dt><code>headers</code> (<code>map(xs:string, xs:string)</code>)</dt>
          <dd>HTTP header fields.</dd>

          <dt><code>content-encoding</code> (<code>xs:string</code>)</dt>
          <dd>Uses a specific content encoding for the request body.
            Supported encodings are <code>gzip</code> and <code>deflate</code>.
            NOTE: Setting the content-encoding option will override any content-encoding
            HTTP header.
          </dd>

          <dt><code>transfer-encoding</code> (<code>xs:string</code>)</dt>
          <dd>Uses a specific transfer encoding for the request body.
            Supported encodings are <code>none</code> and <code>chunked</code>.
            Default is <code>chunked</code> for HTTP 1.1, and <code>none</code>
            for HTTP 1.0.
            NOTE: Setting the transfer-encoding option will override any transfer-encoding
            HTTP header.
            NOTE: <code>chunked</code> is not supported on HTTP 1.0, such use will raise the
            <a>http:version</a> error.
          </dt>

          <dt><code>permit-expired-ssl-certificate</code> (<code>xs:boolean</code>)</dt>
          <dd>This allows HTTPS requests to still work when the server provides an SSL
            certificate which has expired. Default: false.</dd>

          <dt><code>permit-untrusted-ssl-certificate</code> (<code>xs:boolean</code>)</dt>
          <dd>This allows HTTPS requests to still work when the server provides an SSL
            certificate which is not trusted, this may be because the CA (Certificate Authority)
            is unknown</dd>. Default: false.</dd>

          <dt><code>follow-redirect</code> (<code>xs:boolean</code>)</dt>
          <dd>Follow HTTP redirects. Default: true.</dd>

          <dt><code>timeout</code> (<code>xs:decimal</code>)</dt>
          <dd>Maximum number of seconds to wait for a response. Milliseconds may be specified using
            the fractional digits of the xs:decimal e.g. 0.200 is 200 milliseconds.
          </dd>

          <dt><code>certificates</code> (<code>map(xs:string, item()+)+</code>)</dt>
          <dd>Options for authenticating the client with the server using certificate(s). The type
            and use of this option is implementation defined. Java implementations SHOULD use the
            following definition:
            <pre class="example" title="Certificates with a HTTP Client 2.0 Java Implementation">
"certificates": (
  map {
    "trust": map {
      "keystore": "/x/y/my-trust-store.jks",
      "keystore-password": "trust-store-password",
      "alias": "trust-certificate"
    },
    "client": map {
      "keystore": "/x/y/my-client-store.jks",
      "keystore-password": "client-store-password",
      "alias": "my-certificate",
      "password": "my-certificate-password"
    }
  }
)
            </pre>. In the above example the <code>alias</code> options are OPTIONAL.</dd>

          <dt><code>username</code> (<code>xs:string</code>)</dt>
          <dd>Authentication: username.</dd>

          <dt><code>password</code> (<code>xs:string</code>)</dt>
          <dd>Authentication: password.</dd>

          <dt><code>auth-method</code> (<code>xs:string</code>)</dt>
          <dd>Authentication method (Basic, Digest, possibly others). Default: Basic.</dd>

          <dt><code>status-only</code> (<code>xs:boolean</code>)</dt>
          <dd>Skip body in response. Default: false.</dd>

          <dt><code>parse-response</code> (<code>xs:boolean</code>)</dt>
          <dd>Function for parsing the response bodies (see
          <a href="#response-bodies" class="sectionRef"></a>).</dd>

        </dl>

        <pre class="example" title="GET request with User-Agent header, skip body in response">
          http:get('http://expath.org/xyz', map {
            'status-only': true(),
            'headers': map { 'User-Agent': 'EXPath/1.0' }
          })
        </pre>

        <p>
          Authentication data is processed if a non-empty username is supplied:
        </p>

        <pre class="example" title="DELETE request: user authentication">
          http:delete('http://expath.org/xyz', map {
            'username': 'john',
            'password': '****'
          })
        </pre>

        <p>
          The <a href="#errors"><code>http:options</code></a> error will be raised if the value of
          an option is invalid, or if it has an invalid type.
        </p>
      </section>

      <section id='request-body'>
        <h3>Request Body</h3>
        <p>
          Some HTTP methods (such as POST and PUT, and others that are less common) come with a
          request body. In the functions of this document, it can be supplied via the
          <code>$body</code> parameter.
        </p>

        <p>
          If the body is an empty sequence, no data will be sent. Otherwise, the value must have one
          of the following types:
        </p>

        <dd>
          <dt><code>xs:base64Binary</code>, <code>xs:hexBinary</code></dt>
          <dd>Value will be sent as binary data, the media type will be
            <code>application/octet-stream</code>.</dd>

          <dt><code>xs:string</code></dt>
          <dd>The string will be serialized as UTF-8 octets, the media type will be
            <code>text/plain</code>.</dd>

          <dt><code>node()</code></dt>
          <dd>The node will be serialized as XML, the media type will be
            <code>application/xml</code>.</dd>

          <dt><code>map(*)</code></dt>
          <dd>The map will be serialized as JSON string, the media type will be
            <code>application/json</code>.</dd>

          <dt><code>array(*)</code></dt>
          <dd>A Multipart body, the media type will be <code>multipart/mixed</code>.
            Each array member must be a map with a <code>body</code> entry and an optional
            <code>headers</code> entry.</dd>
        </dd>

        <p>
          If the supplied value, or the value of a multipart body, has any other type, the
          <a href="#errors"><code>http:body</code></a> error will be raised.
          <a href="#errors"><code>http:serialize</code></a> will be raised if an error occurs while
          an item is being serialized (e.g. because a supplied map cannot be serialized as JSON).
        </p>

        <p>
          The evaluated media type will be assigned as value of the <code>Content-Type</code> header
          unless a value has been supplied by the user. For multipart requests, each media type
          will be sent as <code>Content-Type</code> in the corresponding multipart header section.
        </p>

        <pre class="example"
             title="PUT request, single body, implicit Content-Type value: text/plain">
          http:put('http://expath.org/xyz', 'plain and simple')
        </pre>

        <pre class="example"
             title="POST request, multipart body, implicit Content-Type value: multipart/mixed">
          http:send('http://expath.org/xyz', 'POST', [
            (: Body 1, implicit Content-Type: application/xml :)
            map {
              'body': &lt;persons&gt;...&lt;/persons&gt;,
            }
            (: Body 2, explicit Content-Type: application/x-object :)
            map {
              'headers': map {
                'Content-Disposition': 'form-data; name="uploadedfile"; filename="hello.o"',
                'Content-Type': 'application/x-object'
              },
              'body': xs:hexBinary('414243')
            }
          ])
        </pre>

        <p>
          If no implicit conversion is available for the desired media type, the body can be
          serialized to a string or binary item in advance:
        </p>

        <pre class="example"
             title="POST request, single body, Content-Type value: application/json">
          http:post(
            'http://expath.org/xyz',
            file:read-text('persons.csv'),
            map { 'headers': 'Content-Type': 'text/csv' }
          )
        </pre>
      </section>
    </section>

    <section id='response'>
      <h2>The Response</h2>
      <p>
        An HTTP response is returned as a map, which may contain the following entries:
      </p>

      <dl>
        <dt><code>http-version</code> (<code>xs:string</code>)</dt>
        <dd>The HTTP Version of the response.</dd>

        <dt><code>status</code> (<code>xs:string</code>)</dt>
        <dd>Status code.</dd>

        <dt><code>message</code> (<code>xs:string</code>)</dt>
        <dd>Status message (also called <i>reason phrase</i>).</dd>

        <dt><code>headers</code> (<code>map(xs:string, xs:string)</code>)</dt>
        <dd>Response headers. The syntax is identical to the request header.</dd>

        <dt><code>body</code> (<code>item()?</code>)</dt>
        <dd>Optional response body.</dd>
      </dl>

      <pre class="example" title="Response of a GET request">
        map {
          "http-version": "1.1",
          "status": "200",
          "message": "OK",
          "headers": map {
            "Date": "Fri, 31 Dec 1999 23:59:59 GMT",
            "Server": "Apache",
            "Content-Type": "text/plain"
          },
          "body": "Happy new year"
        }
      </pre>

      <p>
        If no body is returned, an empty sequence will be returned as body. Otherwise, the value of
        the <code>Content-Type</code> header defines the media-type of the body. The body will
        implicitly be parsed and converted:
      </p>

      <dl>
        <dt><code>multipart/</code> prefix</dt>
        <dd>Multipart body, returned as <code>array(*)</code>. Similar to the returned reponse map,
          each array member will be a map with a <code>headers</code> and a <code>body</code>
          entry. The body will have one of the types of this list.</dd>

        <dt><code>application/xml</code>, <code>application/xml-external-parsed-entity</code>,
          <code>text/xml</code>, <code>text/xml-external-parsed-entity</code>, <code>+xml</code>
          suffix</dt>
        <dd>Parsed as XML, returned as <code>document-node()</code>.</dd>

        <dt><code>application/json</code></dt>
        <dd>Parsed as JSON, returned as <code>map(*)</code>.</dd>

        <dt><code>text/</code> prefix</dt>
        <dd>Parsed as text, returned as <code>xs:string</code>.</dd>

        <dt>any other value</dt>
        <dd>No parsing, returned as <code>xs:base64Binary</code>.</dd>
      </dl>

      <p>
        <a href="#errors"><code>http:parse</code></a> will be raised if an error occurs while
          parsing the body.
      </p>

      <pre class="example" title="Multipart response">
        map {
          "status": "200",
          "message": "OK",
          "headers": map {
            "Content-Type": "multipart/mixed"
          },
          "body": [
            map {
              "headers" : map {
                "Content-Type": "application/json"
              },
              "body": map { "creator": "John", "year": 2018 }
            },
            map {
              "headers" : map {
                "Content-Type": "image/png"
              },
              "body": xs:base64Binary('abcdefgh')
            }
          ]
        }
      </pre>

      <section id='response-bodies'>
        <h3>Parsing of Response Bodies</h3>
        <p>
          If requests are sent to the server, the client has full control over creating the request
          data. This is different for the received response. It can be defective, wrongly typed or
          encoded or incomplete. A client may know, or may want to know more about the sent data,
          or the implicit conversion of response bodies might not match the client’s requirements.
        </p>
        <p>
          Parsing of the response body can be disabled via the <code>parse-response</code> option.
          All bodies of single and multipart responses will be returned as binary items of type
          <code>xs:base64Binary</code>, and the values can be processed (stored, parsed, forwarded)
          in a second step.
        </p>

        <pre class="example" title="XQuery example for parsing response bodies">
          (:~ 
           : Parses a response and returns the parsed body values.
           : @param $response response (top-level, multipart)
           : @return flat sequence with parsed bodies
           :)
          declare function local:parse(
            $response as map(xs:string, item())
          ) as item()* {
            let $type := $response?headers?Content-Type
            let $body := $response?body
            return if(ends-with($type, '/csv') then (
              csv:parse($body)
            ) else if(ends-with($type, '/json') then (
              json:parse($body)
            ) else if(ends-with($type, '/html') then (
              html:parse($body)
            ) else if(starts-with($type, 'multipart/') then (
              (: parse multipart entries recursively :)
              for $part in $body?*
              return local:parse($part)
            ) else (
              error(xs:QName('http:parse'), 'Type not supported: ' || $type)
            )
          };
        
          local:parse(
            http:get('http://expath.org/xyz',
            map { 'parse-response': false() })
          )
        </pre>
        
        <div class="ednote" title="CG">
          These have been my initial suggestions for controlling the parsing of response bodies. In
          the current version, I have chosen Alternative 4, because it will not require
          implementations to support higher-order functions.

          <dl>
            <dt><code>override-media-type</code> (<code>xs:boolean</code>):<br></dt>
            <dd>
              Status Quo: Overrides the returned content-type value.<br>
              + Already available in version 1.0 (adopted from XProc, where is was called
                <code>override-content-type</code>).<br>
              – Only works for single bodies.<br>
            </dd>
  
            <dt><code>parse-response</code>
              (<code>function(xs:base64Binary, xs:string) as item()</code>):</dt>
            <dd>
              Alternative 2. Override the default parsing behavior. Parameters: body, Content-Type
              value.<br>
              + Could be applied to all parts of a multipart response.<br>
              + Direct access to the binary response stream allows us to handle all potential
                conversion errors.<br>
              – String input may possibly be easier to deal with for many XQuery functions.<br>
              – We may need more header information (Encoding, etc.) to correctly handle the
                result.<br>
            </dd>
  
            <dt><code>parse-response</code>
              (<code>function(xs:base64Binary, map(xs:string, xs:string)) as item()</code>):</dt>
            <dd>
              Alternative 2. Parameters: body, response headers.<br>
              + Even more control and information on the sent response.<br>
              – Response handling may get too low-level and technical.<br>
            </dd>
  
            <dt><code>parse-response</code> (<code>function(item()) as item()</code>):</dt>
            <dd>
              Alternative 3. Parameters: parsed body (xs:string, xs:base64Binary,
              document-node())<br>
              + We don’t need to care about binary/string conversion.<br>
              – May fail if server supplies wrong encoding for string conversions.<br>
            </dd>
  
            <dt><code>parse-response</code> (<code>xs:boolean</code>):<br></dt>
            <dd>
              Alternative 4: If disabled, return single and multipart bodies as xs:base64Binary.<br>
              + Multipart responses could still be parsed.<br>
              – Only works for single bodies.<br>
            </dd>
          </dl>
        </div>
      </section>

    </section>

    <section id='errors'>
      <h2>Errors</h2>
      <dl>
        <dt><code>http:body</code></dt>
        <dd>A request body argument has an invalid type.</dd>
        <dt><dfn>http:version</dfn></dt>
        <dd>A feature is not supported by the specified HTTP version.</dd>
        <dt><dfn>http:invalid-uri</dfn></dt>
        <dd>The URI specified in the <a>$uri</a> parameter to the function is invalid with respect
          to the HTTP version in use.</dd>
        <dt><code>http:options</code></dt>
        <dd>The value of an option is invalid, or has an invalid type.</dd>
        <dt><code>http:parse</code></dt>
        <dd>A response body could not be parsed.</dd>
        <dt><code>http:serialize</code></dt>
        <dd>A request body could not be serialized.</dd>
      </dl>
    </section>

    <section class="appendix">
      <h2>Acknowledgements</h2>
      <p>
        Many thanks to Robin Berjon for making the production of this specification much simpler
        with his cool ReSpec tool.
      </p>
    </section>
  </body>
</html>