One document matched: draft-snell-httpbis-mget-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="info" ipr="trust200811" docName="draft-snell-httpbis-mget-00">
<front>
<title abbrev="application/merge-patch">
HTTP/2.0 Discussion: Using Multiple Request URI's in
Idempotent and Safe Requests
</title>
<author initials="J.M." surname="Snell" fullname="James M Snell">
<address>
<email>jasnell@gmail.com</email>
</address>
</author>
<date month="March" year="2013" />
<keyword>I-D</keyword>
<keyword>http</keyword>
<keyword>spdy</keyword>
<abstract>
<t>This memo describes a proposed mechanism for specifying
multiple request URI's within Idempotent methods (i.e. "Multi-GET",
"Multi-Delete")</t>
</abstract>
</front>
<middle>
<section title="Using Multiple-Request URIs">
<t>This document introduces the concept of allowing Idempotent and Safe
HTTP/2 requests to contain multiple, independent Request URIs. For
example, if a User-Agent wishes to retrieve multiple image resources from
a server, it could send a single GET request separately listing each of
the resources being requested:</t>
<texttable>
<preamble>An example "Multi-GET" request</preamble>
<ttcol>Header</ttcol>
<ttcol>Value</ttcol>
<c>:method</c>
<c>GET</c>
<c>:path</c>
<c>"/images/foo.png", "/images/bar.png"</c>
<c>:host</c>
<c>example.org</c>
</texttable>
<figure><preamble>Upon receiving this request, a server supporting
multiple Request URIs would respond by initiating two distinct
response streams back to the requesting-user agent, one for each
of the requested resources:</preamble>
<artwork><![CDATA[
UA SERVER
----------------------
| |
| MGET REQUEST |
|--------------->|
| |
| Resp#1:foo.png |
|<---------------|
| Resp#2:bar.png |
|<---------------|
| |
]]></artwork></figure>
<t>This singular Multiple-GET request is semantically equivallent to
sending two simultaneous, separate GET requests for each of the two
resources. There is no implicit or explicit ordering or relationship
between the resources being requested. Each has their own distinct
response stream, with it's own headers and response status code. The
server can choose to return the requested resources in any order it
chooses.</t>
<texttable>
<preamble>All request header fields included in the request apply equally to each of the listed request URIs. To perform a conditional GET request using the If-None-Match request header, for example, the entity tags for each of the requested resources would be listed:</preamble>
<ttcol>Header</ttcol>
<ttcol>Value</ttcol>
<c>:method</c>
<c>GET</c>
<c>:path</c>
<c>"/images/foo.png", "/images/bar.png"</c>
<c>:host</c>
<c>example.org</c>
<c>if-none-match</c>
<c>"some-opaque-etag", "another-opaque-etag"</c>
</texttable>
<t>The condition would be evaluated for each of the requested URIs; that
is, each of the listed Entity Tags would be evaluated against each of
the individual requested resources, preserving the existing semantics
of the conditional headers and enforcing the notion that a Multi-GET
is semantically equivalent to multiple, simultaneous independent
GET requests.</t>
<t>Because each of the requested resources are returned using separately
identifiable response streams, each with their own set of metadata,
response status codes and data frames, intermediate caches with support
for Multiple Request URIs can simply and transparently "do the right
thing".</t>
<figure>
<artwork><![CDATA[
UA CACHE SERVER
----------------------------------------
| | |
| MGET REQUEST | |
|foo.png, bar.png| |
|--------------->| GET REQUEST |
| | bar.png |
| Resp#1:foo.png |--------------->|
|<---------------| |
| | Resp:bar.png |
| Resp#2:bar.png |<---------------|
|<---------------| |
| | |
]]></artwork></figure>
<t>Here, the intermediate cache receives the initial GET containing
multiple request URIs and determines that one of the resources (foo.png)
can be served from it's cache, while the second (bar.png) needs to be
fetched from the origin server. From the User-Agents point of view, this
action is entirely transparent.</t>
<t>Because such requests are semantically equivalent to multiple,
simultaneous individual requests, translating to and from HTTP/1
becomes a simple matter of splitting out each request URI into
its own distinct HTTP/1 request, each with its own exact copy of
the full set of request header fields. Intermediaries should be able
to handle the translation in a manner that is completely transparent
to the User-Agent.</t>
<figure>
<artwork><![CDATA[
UA PROXY SERVER
----------------------------------------
| | |
| MGET REQUEST | |
|foo.png, bar.png| |
|--------------->| GET REQUEST |
| | foo.png |
| |--------------->|
| | GET REQUEST |
| | bar.png |
| |--------------->|
| | Resp:foo.png |
| |<---------------|
| Resp#1:foo.png | |
|<---------------| Resp:bar.png |
| Resp#2:bar.png |<---------------|
|<---------------| |
| | |
]]></artwork></figure>
<t>Multiple Request URIs are only permitted on requests methods that are
known to be both Safe and Idempotent with one notable exception: The
DELETE method, which is Idempotent but not Safe MAY include multiple
request URIs.</t>
<texttable>
<preamble>An example Multi-HEAD Request:</preamble>
<ttcol>Header</ttcol>
<ttcol>Value</ttcol>
<c>:method</c>
<c>HEAD</c>
<c>:path</c>
<c>"/images/foo.png", "/images/bar.png"</c>
<c>:host</c>
<c>example.org</c>
</texttable>
<texttable>
<preamble>An example Multi-DELETE Request:</preamble>
<ttcol>Header</ttcol>
<ttcol>Value</ttcol>
<c>:method</c>
<c>DELETE</c>
<c>:path</c>
<c>"/images/foo.png", "/images/bar.png"</c>
<c>:host</c>
<c>example.org</c>
</texttable>
<t>In particular, Multiple Request URIs MUST NOT ever be used for
POST or PUT requests and SHOULD NOT be used for any other request
method carrying a request entity unless the method is known to be
both Safe and Idempotent.</t>
<t>Server support for Multiple-Request URIs within HTTP/2
implementations ought to be required. If, however, the working
group decides that the mechanism is to be optional, a server
endpoint not supporting multiple request URIs can return a 400
"Bad Request" error when it receives such requests. A mechanism
such as Mark Nottingham's proposed "Browser Hints" format can be
used to communicate to User-Agents whether or not multiple request
URIs are supported on a given host.</t>
<t>Whether and when to bundle multiple request URIs into a single
GET request is entirely up to the requesting HTTP/2 client. A
user-agent that is attempting to optimize page load times, for
instance, could choose to send a mix of multi- and single-request URI
requests to the server depending on whatever strategy it chooses
for optimization.</t>
<section title=""Globbed" Requests">
<t>This document specifically rules out the notion of "globbed"
Multi-Requests. That is, sending a request with a single "wildcard"
request URI that returns multiple independent streams, e.g.:</t>
<texttable>
<preamble>An example "Multi-GET" request</preamble>
<ttcol>Header</ttcol>
<ttcol>Value</ttcol>
<c>:method</c>
<c>GET</c>
<c>:path</c>
<c>"/images/*.png"</c>
<c>:host</c>
<c>example.org</c>
</texttable>
<t>The reason this is not defined is because such requests play
havoc with the existing HTTP Caching Model, greatly complicates
implementation and carries with it a variety of security risks.</t>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:24:28 |