diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml
index 92e7bcf27..e89eedc2b 100644
--- a/draft-ietf-httpbis-semantics-latest.xml
+++ b/draft-ietf-httpbis-semantics-latest.xml
@@ -4772,16 +4772,9 @@ Content-Encoding: gzip
between the related resources.
- An origin server that allows PUT on a given target resource &MUST; send a
- 400 (Bad Request) response to a PUT request that contains a
- Content-Range header field (), since
- the content is likely to be a partial representation mistakenly PUT as
- a full representation.
- Partial content updates are possible by targeting a separately identified
- resource with state that overlaps a portion of the larger resource, or by
- using a different method that has been specifically defined for partial
- updates (for example, the PATCH method defined in
- ).
+ Some origin servers support use of the Content-Range header
+ field () as a request modifier to
+ perform a partial PUT, as described in .
Responses to the PUT method are not cacheable. If a successful PUT request
@@ -7790,9 +7783,11 @@ bytes=500-700,601-999
A proxy that receives such a message &SHOULD; forward it downstream.
+ Content-Range might also be sent as a request modifier to request a
+ partial PUT, as described in , based on private
+ agreements between client and origin server.
A server &MUST; ignore a Content-Range header field received in a request
- with a method for which Content-Range support is not defined. No request
- method in this specification is defined to support Content-Range in a request.
+ with a method for which Content-Range support is not defined.
For byte ranges, a sender &SHOULD; indicate the complete length of the
@@ -7870,6 +7865,38 @@ Content-Range: bytes 734-1233/1234
+
+
+
+
+ Some origin servers support PUT of a partial representation
+ when a Content-Range header field
+ () is sent in the request, though
+ such support is inconsistent and depends on private agreements with
+ user agents. In general, it requests that the state of the
+ target resource be partly replaced with the enclosed content
+ at an offset and length indicated by the Content-Range value, where the
+ offset is relative to the current selected representation.
+
+
+ An origin server &SHOULD; respond with a 400 (Bad Request)
+ status code if it receives Content-Range on a PUT for a
+ target resource that does not support partial PUT requests.
+
+
+ Partial PUT is not backwards compatible with the original definition of PUT.
+ It may result in the content being written as a complete replacement for the
+ current representation.
+
+
+ Partial resource updates are also possible by targeting a separately
+ identified resource with state that overlaps or extends a portion of the
+ larger resource, or by using a different method that has been specifically
+ defined for partial updates (for example, the PATCH method defined in
+ ).
+
+
+
@@ -12914,6 +12941,11 @@ Content-Type: text/plain
applicability.
()
+
+ Allowed use of the Content-Range header field
+ () as a request modifier on PUT.
+ ()
+
@@ -12961,6 +12993,12 @@ Content-Type: text/plain
It is now possible to define Range handling on extension methods.
()
+
+ Described use of the Content-Range header field
+ () as a request modifier to perform a
+ partial PUT.
+ ()
+
@@ -13272,7 +13310,7 @@ Content-Type: text/plain
- In , remove the unused "accept parameters" ()
- In , mention that RFC 1945 describes HTTP/0.9 as well ()
- - In , clarify that Content-Range is to be ignored in requests ()
+ - In , describe non-standard use of the Content-Range header field () as a request modifier to perform a partial PUT ()
- In , import the 421 (Misdirected Request) status code from ()
- In , rephrase the actual recipient parsing requirements ()
- In , mention request target forms in considerations for new methods ()