draft-ietf-httpbis-safe-method-w-body.xml

<?xml version="1.0"?>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc-ext xml2rfc-backend="202007"?>
<?github-issue-label query-method?>
<!DOCTYPE rfc [
  <!ENTITY MAY "<bcp14>MAY</bcp14>">
  <!ENTITY MUST "<bcp14>MUST</bcp14>">
  <!ENTITY MUST-NOT "<bcp14>MUST NOT</bcp14>">
  <!ENTITY OPTIONAL "<bcp14>OPTIONAL</bcp14>">
  <!ENTITY RECOMMENDED "<bcp14>RECOMMENDED</bcp14>">
  <!ENTITY REQUIRED "<bcp14>REQUIRED</bcp14>">
  <!ENTITY SHALL "<bcp14>SHALL</bcp14>">
  <!ENTITY SHALL-NOT "<bcp14>SHALL NOT</bcp14>">
  <!ENTITY SHOULD "<bcp14>SHOULD</bcp14>">
  <!ENTITY SHOULD-NOT "<bcp14>SHOULD NOT</bcp14>">
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-httpbis-safe-method-w-body-latest" submissionType="IETF" version="3" xmlns:xi="http://www.w3.org/2001/XInclude">
  <front>
    <title>
      The HTTP QUERY Method
    </title>

    <author initials="J." surname="Reschke" fullname="Julian Reschke">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address>
        <postal>
          <street>Hafenweg 16</street>
          <city>Münster</city><code>48155</code>
          <country>Germany</country>
        </postal>
        <email>julian.reschke@greenbytes.de</email>
        <uri>https://greenbytes.de/tech/webdav/</uri>
      </address>
    </author>
    <author initials="A." surname="Malhotra" fullname="Ashok Malhotra">
      <address>
        <email>malhotrasahib@gmail.com</email>
      </address>
    </author>
     <author initials="J.M." surname="Snell" fullname="James M Snell">
      <address>
        <email>jasnell@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Akamai</organization>
      <address>
        <email>mbishop@evequefou.be</email>
      </address>
    </author>

    <date/>

    <area>Web and Internet Transport</area>
    <workgroup>HTTP</workgroup>
    <keyword>http</keyword>
    <keyword>query</keyword>
    <keyword>method</keyword>

    <abstract>
      <t>
        This specification defines a new HTTP method, QUERY, as a safe, idempotent
        request method that can carry request content.
      </t>
    </abstract>

    <note title="Editorial Note" removeInRFC="true">
      <t>
        Discussion of this draft takes place on the HTTP working group
        mailing list (ietf-http-wg@w3.org), which is archived at
        <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
      </t>
      <t>
        Working Group information can be found at <eref target="https://httpwg.org/"/>;
        source code and issues list for this draft can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/query-method"/>.
      </t>
      <t>
        The changes in this draft are summarized in <xref target="changes.since.07"/>.
      </t>
    </note>

  </front>

  <middle>

  <section anchor="intro" title="Introduction">
    <t>
      This specification defines the HTTP QUERY request method as a means of
      making a safe, idempotent request that contains content.
    </t>
    <t>
      Most often, this is desirable when the data conveyed in a request is
      too voluminous to be encoded into the request's URI. For example,
      this is a common query pattern:
    </t>
<artwork type="http-message">
GET /feed?q=foo&amp;limit=10&amp;sort=-published HTTP/1.1
Host: example.org
</artwork>
    <t>
      However, for a query with parameters that are complex or large in size,
      encoding it in the request URI may not be the best option because
    </t>
    <ul>
      <li>often size limits are not known ahead of time because a request can pass through many uncoordinated
    system (but note that <xref section="4.1" target="HTTP"/> recommends senders and recipients to support at least 8000 octets),</li>
      <li>expressing certain kinds of data in the target URI is inefficient because of the overhead of encoding that data into a valid URI, and</li>
      <li>encoding query parameters directly into the request URI effectively casts every possible combination of query inputs as distinct
          resources.</li>
    </ul>
    <t>
      As an alternative to using GET, many implementations make use of the
      HTTP POST method to perform queries, as illustrated in the example
      below. In this case, the input parameters to the query operation are
      passed along within the request content as opposed to using the
      request URI.
    </t>
    <t>
      A typical use of HTTP POST for requesting a query:
    </t>
<artwork type="http-message">
POST /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded

q=foo&amp;limit=10&amp;sort=-published
</artwork>
    <t>
      This variation, however, suffers from the same basic limitation as GET
      in that it is not readily apparent -- absent specific knowledge of the
      resource and server to which the request is being sent -- that a safe,
      idempotent query is being performed.
    </t>
    <t>
      The QUERY method provides a solution that spans the gap between the use of GET and POST, with
      the example above being expressed as:
    </t>
<artwork type="http-message">
QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded

q=foo&amp;limit=10&amp;sort=-published
</artwork>
    <t>
      As with POST, the input to the query operation is passed along within the content of the request
      rather than as part of the request URI. Unlike POST, however, the method is explicitly safe
      and idempotent, allowing functions like caching and automatic retries to operate.
    </t>
    <t>Summarizing:</t>
    <table>
      <thead>
        <tr>
          <th/>
          <th>GET</th>
          <th>QUERY</th>
          <th>POST</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td>Safe</td>
          <td>yes</td>
          <td>yes</td>
          <td>potentially no</td>
        </tr>
        <tr>
          <td>Idempotent</td>
          <td>yes</td>
          <td>yes</td>
          <td>potentially no</td>
        </tr>
        <tr>
          <td>Cacheable</td>
          <td>yes</td>
          <td>yes</td>
          <td>no</td>
        </tr>
        <tr>
          <td>Content (body)</td>
          <td>"no defined semantics"</td>
          <td>expected (semantics per target resource)</td>
          <td>expected (semantics per target resource)</td>
        </tr>
      </tbody>
    </table>

    <section title="Terminology" anchor="terminology">
      <t>
        This document uses terminology defined in <xref section="3" target="HTTP"/>.
      </t>
    </section>

    <section title="Notational Conventions" anchor="notational.coventions">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.
      </t>
    </section>

  </section>

  <section title="QUERY" anchor="query">
    <t>
      The QUERY method is used to initiate a server-side query. Unlike
      the HTTP GET method, which requests that a server return a
      representation of the resource identified by the target URI
      (as defined by <xref target="HTTP" section="7.1"/>), the QUERY
      method is used to ask the server to perform a query operation
      (described by the request content) over some set of data scoped to the
      target URI. The content returned in response to a QUERY
      cannot be assumed to be a representation of the resource identified by
      the target URI.
    </t>
    <t>
      The content of the request defines the query. Implementations &MAY; use
      a request content of any media type with the QUERY method, provided that it
      has appropriate query semantics.
    </t>
    <t>
      QUERY requests are both safe and idempotent with regards to the
      resource identified by the request URI. That is, QUERY requests do not
      alter the state of the targeted resource. However, while processing a
      QUERY request, a server can be expected to allocate computing and memory
      resources or even create additional HTTP resources through which the
      response can be retrieved.
    </t>
    <t>
      A successful response to a QUERY request is expected to provide some
      indication as to the final disposition of the operation. For
      instance, a successful query that yields no results can be represented
      by a 204 No Content response. If the response includes content,
      it is expected to describe the results of the operation.
    </t>

    <section title="Content-Location and Location Fields" anchor="location">
    <t>
      Furthermore, a successful response can include a Content-Location
      header field (see <xref target="HTTP" section="8.7"/>) containing an
      identifier for a resource corresponding to the results of the
      operation. This represents a claim from the server that a client can send
      a GET request for the indicated URI to retrieve the results of the query
      operation just performed. The indicated resource might be temporary.
    </t>
    <t>
      A server &MAY; create or locate a resource that identifies the query
      operation for future use. If the server does so, the URI of the resource
      can be included in the Location header field of the response (see <xref
      target="HTTP" section="10.2.2"/>). This represents a claim that a client can
      send a GET request to the indicated URI to repeat the query operation just
      performed without resending the query parameters. This resource might be
      temporary; if a future request fails, the client can retry using the
      original QUERY resource and the previously submitted parameters again.
    </t>
    </section>

    <section title="Redirection" anchor="redirection">
    <t>
      In some cases, the server may choose to respond indirectly to the QUERY
      request by redirecting the user agent to a different URI (see
      <xref target="HTTP" section="15.4"/>). The semantics of the redirect
      response do not differ from other methods. For instance, a 303 (See Other)
      response would indicate that the Location field identifies an
      alternate URI from which the results can be retrieved
      using a GET request (this use case is also covered by the
      use of the Location response field in a 2xx response).
      On the other hand, response codes 307 (Temporary Redirect) and 308
      (Permanent Redirect) can be used to request the user agent to redo
      the QUERY request on the URI specified by the Location field.
      Various non-normative examples of successful
      QUERY responses are illustrated in <xref target="examples" />.
    </t>
    </section>

    <section title="Conditional Requests" anchor="conditional">
    <t>
      A conditional QUERY requests that the selected representation
      (i.e., the query results, after any content negotiation) be
      returned in the response only under the circumstances described by the
      conditional header field(s), as defined in
      <xref target="HTTP" section="13"/>.
    </t>
    </section>

    <section title="Caching" anchor="caching">
      <t>
        The response to a QUERY method is cacheable; a cache &MAY; use it to satisfy subsequent
        QUERY requests as per <xref target="HTTP-CACHING" section="4"/>).
      </t>
      <t>
        The cache key for a query (see <xref target="HTTP-CACHING" section="2"/>) &MUST;
        incorporate the request content. When doing so, caches &SHOULD; first normalize request
        content to remove semantically insignificant differences, thereby improving cache
        efficiency, by:
      </t>
      <ul>
        <li>Removing content encoding(s)</li>
        <li>Normalizing based upon knowledge of format conventions, as indicated by the any media type suffix in the request's Content-Type field (e.g., "+json")</li>
        <li>Normalizing based upon knowledge of the semantics of the content itself, as indicated by the request's Content-Type field.</li>
      </ul>
      <t>
        Note that any such normalization is performed solely for the purpose of generating a cache key; it
        does not change the request itself.
      </t>
      </section>
  </section>

  <section title="The &quot;Accept-Query&quot; Header Field" anchor="field.accept-query">
    <t>
      The "Accept-Query" response header field can be used by a resource to
      directly signal support for the QUERY method while identifying
      the specific query format media type(s) that may be used.
    </t>
    <t>
      "Accept-Query" contains a list of media ranges (<xref target="HTTP" section="12.5.1"/>)
      using "Structured Fields" syntax (<xref target="STRUCTURED-FIELDS"/>).
      Media ranges are represented by a List Structured Header Field of either Tokens or
      Strings, containing the media range value without parameters. Parameters,
      if any, are mapped to Parameters of type String.
    </t>
    <t>
      The choice of Token vs. String is semantically insignificant. That is,
      recipients &MAY; convert Tokens to Strings, but &MUST-NOT; process them
      differently based on the received type.
    </t>
    <t>
      Media types do not exactly map to Tokens, for instance they
      allow a leading digit. In cases like these, the String format needs to
      be used.
    </t>
    <t>
      The only supported uses of wildcards are "*/*", which matches any type,
      or "xxxx/*", which matches any subtype of the indicated type.
    </t>
    <t>
      The order of types listed in the field value is not significant.
    </t>
    <t>
      The only allowed format for parameters is String.
    </t>
    <t>
      Accept-Query's value applies to every URI on the server that shares the same path; in
      other words, the query component is ignored. If requests to the same resource return
      different Accept-Query values, the most recently received fresh value (per
      <xref target="HTTP-CACHING" section="4.2"/>) is used.
    </t>
    <t>
      Example:
    </t>
    <artwork type="example">
Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"</artwork>
    <t>
      Although the syntax for this field appears to be similar to other
      fields, such as "Accept" (<xref target="HTTP" section="12.5.1"/>),
      it is a Structured Field and thus &MUST; be processed as specified in
      <xref target="STRUCTURED-FIELDS" section="4"/>.
    </t>
  </section>

  <section title="Security Considerations">
    <t>
      The QUERY method is subject to the same general security
      considerations as all HTTP methods as described in
      <xref target="HTTP"/>.
    </t>
    <t>
      It can be used as an alternative to passing request
      information in the URI (e.g., in the query section). This is preferred in some
      cases, as the URI is more likely to be logged or otherwise processed
      by intermediaries than the request content.
      If a server creates a temporary resource to represent the results of a QUERY
      request (e.g., for use in the Location or Content-Location field) and the request
      contains sensitive information that cannot be logged, then the URI of this
      resource &SHOULD; be chosen such that it does not include any sensitive
      portions of the original request content.
    </t>
    <t>
      Caches that normalize QUERY content incorrectly or in ways that are
      significantly different than how the resource processes the content
      can return the incorrect response if normalization results in a false positive.
    </t>
    <t>
      A QUERY request from user agents implementing CORS (Cross-Origin Resource Sharing)
      will require a "preflight" request,
      as QUERY does not belong to the set of CORS-safelisted methods
      (see "<eref target="https://fetch.spec.whatwg.org/#methods">Methods</eref>" in
      <xref target="FETCH"/>).
    </t>
  </section>

  <section title="IANA Considerations" anchor="iana.considerations">

    <section title="Registration of QUERY method" anchor="method.registration">
      <t>
        IANA is requested to add the QUERY method to the HTTP
        Method Registry at <eref brackets="angle" target="http://www.iana.org/assignments/http-methods"/>
        (see <xref target="HTTP" section="16.3.1"/>).
      </t>
      <table>
        <thead>
          <tr>
            <th>Method Name</th>
            <th>Safe</th>
            <th>Idempotent</th>
            <th>Specification</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>QUERY</td>
            <td>Yes</td>
            <td>Yes</td>
            <td><xref target="query"/></td>
          </tr>
        </tbody>
      </table>
    </section>

    <section title="Registration of Accept-Query field" anchor="field.registration">
      <t>
        IANA is requested to add the Accept-Query field to the HTTP Field Name
        Registry at <eref brackets="angle" target="https://www.iana.org/assignments/http-fields"/>
        (see <xref target="HTTP" section="16.1.1"/>).
      </t>
      <table>
        <thead>
          <tr>
            <th>Field Name</th>
            <th>Status</th>
            <th>Structured Type</th>
            <th>Reference</th>
            <th>Comments</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>Accept-Query</td>
            <td>permanent</td>
            <td>List</td>
            <td><xref target="field.accept-query"/> of this document.</td>
            <td></td>
          </tr>
        </tbody>
      </table>
    </section>
</section>
</middle>
<back>
  <references title="Normative References">
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
    <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
    <reference anchor="HTTP">
      <front>
        <title>HTTP Semantics</title>
        <author fullname="Roy T. Fielding" initials="R." surname="Fielding" role="editor"/>
        <author fullname="Mark Nottingham" initials="M." surname="Nottingham" role="editor"/>
        <author fullname="Julian Reschke" initials="J." surname="Reschke" role="editor"/>
        <date year="2022" month="June"/>
      </front>
      <seriesInfo name="STD" value="97"/>
      <seriesInfo name="RFC" value="9110"/>
    </reference>
    <reference anchor="HTTP-CACHING">
      <front>
        <title>HTTP Caching</title>
        <author fullname="Roy T. Fielding" initials="R." surname="Fielding" role="editor"/>
        <author fullname="Mark Nottingham" initials="M." surname="Nottingham" role="editor"/>
        <author fullname="Julian Reschke" initials="J." surname="Reschke" role="editor"/>
        <date year="2022" month="June"/>
      </front>
      <seriesInfo name="STD" value="98"/>
      <seriesInfo name="RFC" value="9111"/>
    </reference>
    <reference anchor="STRUCTURED-FIELDS">
      <front>
        <title>Structured Field Values for HTTP</title>
        <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
          <organization>Cloudflare</organization>
        </author>
        <author initials="P-H." surname="Kamp" fullname="Poul-Henning Kamp">
          <organization>The Varnish Cache Project</organization>
        </author>
        <date year="2024" month="September"/>
      </front>
      <seriesInfo name="RFC" value="9651"/>
    </reference>
  </references>
  <references title="Informative References">
    <reference anchor="FETCH" target="https://fetch.spec.whatwg.org">
      <front>
        <title>FETCH</title>
        <author><organization>WHATWG</organization></author>
      </front>
    </reference>
  </references>

  <section title="Examples" anchor="examples">
<!-- TODO: add Content-Length fields once examples are stable -->
    <t>
      The non-normative examples in this section make use of a simple,
      hypothetical plain-text based query syntax based on SQL with results
      returned as comma-separated values. This is done for illustration
      purposes only. Implementations are free to use any format they wish on
      both the request and response.
    </t>

    <section title="Simple QUERY with a Direct Response">

      <t>A simple query with a direct response:</t>
<artwork type="http-message">
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/sql
Accept: text/csv

select surname, givenname, email limit 10
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 200 OK
Content-Type: text/csv

surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
</artwork>

    </section>

    <section title="Simple QUERY with a Direct Response and Location Fields">

      <t>A simple query with a direct response:</t>
<artwork type="http-message">
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/sql
Accept: text/csv

select surname, givenname, email limit 10
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17

surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
</artwork>

    <t>
      A subsequent GET request on /contacts/responses/42 would return
      the same response, until the server decides to remove that
      resource.
    </t>
    <t>
      A GET request on /contacts/queries/17 however would execute the same
      query again, and return a fresh result for that query:
    </t>

<artwork type="http-message">
GET /contacts/queries/17 HTTP/1.1
Host: example.org
Accept: text/csv
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/43

surname, givenname, email
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
</artwork>

    </section>

    <section title="Simple QUERY with Indirect Response (303 See Other)">

      <t>A simple query with an Indirect Response (303 See Other):</t>
<artwork type="http-message">
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/sql
Accept: text/csv

select surname, givenname, email limit 10
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 303 See Other
Location: /contacts/query123
</artwork>

      <t>Retrieval of the Query Response:</t>
<artwork type="http-message">
GET /contacts/query123 HTTP/1.1
Host: example.org
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 200 OK
Content-Type: text/csv

surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
</artwork>

    </section>

    <section title="Simple QUERY with Redirect Response (308 Moved Permanently)">

      <t>A simple query being redirected:</t>
<artwork type="http-message">
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/sql
Accept: text/csv

select surname, givenname, email limit 10
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 308 Moved Permanently
Location: /morecontacts
</artwork>

      <t>Redirected request:</t>
<artwork type="http-message">
QUERY /morecontacts HTTP/1.1
Host: example.org
Content-Type: application/sql
Accept: text/csv

select surname, givenname, email limit 10
</artwork>

      <t>Response:</t>
<artwork type="http-message">
HTTP/1.1 200 OK
Content-Type: text/csv

surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
</artwork>

    </section>
  </section>

<section title="Change Log" anchor="change.log" removeInRFC="true">
<section title="Since draft-ietf-httpbis-safe-method-w-body-00" anchor="changes.since.00">
<ul>
  <li>Use "example/query" media type instead of undefined "text/query" (<eref target="https://github.com/httpwg/http-extensions/issues/1450"/>)</li>
  <li>In <xref target="field.accept-query"/>, adjust the grammar to just define the field value (<eref target="https://github.com/httpwg/http-extensions/issues/1470"/>)</li>
  <li>Update to latest HTTP core spec, and adjust terminology accordingly (<eref target="https://github.com/httpwg/http-extensions/issues/1473"/>)</li>
  <li>Reference RFC 8174 and markup bcp14 terms (<eref target="https://github.com/httpwg/http-extensions/issues/1497"/>)</li>
  <li>Update HTTP reference (<eref target="https://github.com/httpwg/http-extensions/issues/1524"/>)</li>
  <li>Relax restriction of generic XML media type in request content (<eref target="https://github.com/httpwg/http-extensions/issues/1535"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-01" anchor="changes.since.01">
<ul>
  <li>Add minimal description of cacheability (<eref target="https://github.com/httpwg/http-extensions/issues/1552"/>)</li>
  <li>Use "QUERY" as method name (<eref target="https://github.com/httpwg/http-extensions/issues/1614"/>)</li>
  <li>Update HTTP reference (<eref target="https://github.com/httpwg/http-extensions/issues/1669"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-02" anchor="changes.since.02">
<ul>
  <li>In <xref target="field.accept-query"/>, slightly rephrase statement about significance of ordering (<eref target="https://github.com/httpwg/http-extensions/issues/1896"/>)</li>
  <li>Throughout: use "content" instead of "payload" or "body" (<eref target="https://github.com/httpwg/http-extensions/issues/1915"/>)</li>
  <li>Updated references (<eref target="https://github.com/httpwg/http-extensions/issues/2157"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-03" anchor="changes.since.03">
<ul>
  <li>In <xref target="field.accept-query"/>, clarify scope (<eref target="https://github.com/httpwg/http-extensions/issues/1913"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-04" anchor="changes.since.04">
<ul>
  <li>Describe role of Content-Location and Location fields (<eref target="https://github.com/httpwg/http-extensions/issues/1745"/>)</li>
  <li>Added Mike Bishop as author (<eref target="https://github.com/httpwg/http-extensions/issues/2837"/>)</li>
  <li>Use "target URI" instead of "effective request URI" (<eref target="https://github.com/httpwg/http-extensions/issues/2883"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-05" anchor="changes.since.05">
<ul>
  <li>Updated language and examples about redirects and method rewriting (<eref target="https://github.com/httpwg/http-extensions/issues/1917"/>)</li>
  <li>Add QUERY example to introduction (<eref target="https://github.com/httpwg/http-extensions/issues/2171"/>)</li>
  <li>Update "Sensitive information in QUERY URLs" (<eref target="https://github.com/httpwg/http-extensions/issues/2853"/>)</li>
  <li>Field registration for "Accept-Query" (<eref target="https://github.com/httpwg/http-extensions/issues/2903"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-06" anchor="changes.since.06">
<ul>
  <li>Improve language about sensitive information in URIs (<eref target="https://github.com/httpwg/http-extensions/issues/1895"/>)</li>
  <li>Guidance about what's possible with GET wrt URI length (<eref target="https://github.com/httpwg/http-extensions/issues/1914"/>)</li>
  <li>Clarified description of conditional queries (<eref target="https://github.com/httpwg/http-extensions/issues/1917"/>)</li>
  <li>Editorial changes to Introduction (ack Will Hawkins, <eref target="https://github.com/httpwg/http-extensions/pull/2859"/>)</li>
  <li>Added Security Consideration with respect to Normalization (<eref target="https://github.com/httpwg/http-extensions/issues/2896"/>)</li>
  <li>Added CORS considerations (<eref target="https://github.com/httpwg/http-extensions/issues/2898"/>)</li>
  <li>Make Accept-Query a Structured Field (<eref target="https://github.com/httpwg/http-extensions/issues/2934"/>)</li>
  <li>SQL media type is application/sql (RFC6922) (<eref target="https://github.com/httpwg/http-extensions/issues/2936"/>)</li>
  <li>Added overview table to introduction (<eref target="https://github.com/httpwg/http-extensions/issues/2951"/>)</li>
  <li>Reference HTTP spec for terminology (<eref target="https://github.com/httpwg/http-extensions/issues/2953"/>)</li>
  <li>Moved BCP14 related text into subsection (<eref target="https://github.com/httpwg/http-extensions/issues/2954"/>)</li>
  <li>Move examples into index (<eref target="https://github.com/httpwg/http-extensions/issues/2957"/>)</li>
</ul>
</section>
<section title="Since draft-ietf-httpbis-safe-method-w-body-07" anchor="changes.since.07">
  <t>None yet.</t>
</section>
</section>

</back>
</rfc>