From 7f7d335724c1af53ce4862d8c59bfcb69fdb7fcd Mon Sep 17 00:00:00 2001 From: Craig Pratt Date: Mon, 9 Apr 2018 02:10:08 -0700 Subject: [PATCH] Made all references to "very large"/"very large values" lower case Also changed exponent notation from "^^" to "^" --- draft-ietf-httpbis-rand-access-live.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-rand-access-live.xml b/draft-ietf-httpbis-rand-access-live.xml index 0c7be58f9..c482d7dfa 100644 --- a/draft-ietf-httpbis-rand-access-live.xml +++ b/draft-ietf-httpbis-rand-access-live.xml @@ -282,7 +282,7 @@ Content-Range: bytes 0-1234567/* Specifically, last-byte-pos is required in byte-range. So in order to preserve interoperability with existing HTTP clients, servers, proxies, and caches, this document proposes a mechanism for a client to indicate support for handling an indeterminate-length byte-range response, and a mechanism for a server to indicate if/when it's providing a indeterminate-length response. - A client can indicate support for handling indeterminate-length byte-range responses by providing a Very Large Value for the last-byte-pos in the byte-range request. For example, a client can perform a byte-range GET request of the form: + A client can indicate support for handling indeterminate-length byte-range responses by providing a very large value for the last-byte-pos in the byte-range request. For example, a client can perform a byte-range GET request of the form:
GET /resource HTTP/1.1 @@ -484,9 +484,9 @@ Content-Range: bytes 1020000-1254567/*
- One potential issue with this recommendation is related to the use of very-large last-byte-pos values. Some client and server implementations may not be prepared to deal with byte position values of 2^^63 and beyond. So in applications where there's no expectation that the representation will ever exceed 2^^63, a value smaller than this value should be used as the Very Large last-byte-pos in a byte-seek request or content-range response. + One potential issue with this recommendation is related to the use of very-large last-byte-pos values. Some client and server implementations may not be prepared to deal with byte position values of 2^63 and beyond. So in applications where there's no expectation that the representation will ever exceed 2^63, a value smaller than this value should be used as the very large last-byte-pos in a byte-seek request or content-range response. - Also, some implementations (e.g. JavaScript-based clients and servers) are not able to represent all values beyond 2^^53. So similarly, if there's no expectation that a representation will ever exceed 2^^53 bytes, values smaller than this limit should be used for the last-byte-pos in byte-range requests. + Also, some implementations (e.g. JavaScript-based clients and servers) are not able to represent all values beyond 2^53. So similarly, if there's no expectation that a representation will ever exceed 2^53 bytes, values smaller than this limit should be used for the last-byte-pos in byte-range requests.