Range Patch
draft-toomim-httpbis-range-patch-00

Document Type Active Internet-Draft (individual)
Last updated 2019-11-18
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet-Draft                                            M. Milutinovic
Expires: Mar 16, 2020                                        UC Berkeley
Intended status: Proposed Standard                             M. Toomim
                                                       Invisible College
                                                              B. Bellomy
                                                       Invisible College
                                                            Nov 18, 2019

                             Range Patch
                  draft-toomim-httpbis-range-patch-00

Abstract

   A uniform approach for expressing changes to state over HTTP.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.  The list of current Internet-Drafts is at
   http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   https://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   https://www.ietf.org/shadow.html




Table of Contents

   1. Introduction ....................................................3
   2. Range Patch .....................................................3
      2.1. Multiple Range Patches .....................................5
      2.2. Stand-Alone Range Patch ....................................5
      2.3. URI Fragment Identifiers ...................................6
   3. Range Units .....................................................7
      3.1. Bytes Range Unit ...........................................7
      3.2. JSON Range Unit ............................................8
      3.3. Lines Range Unit ..........................................10
   4. IANA Considerations ............................................11
      4.1. Range Unit Registrations ..................................11
      4.2. The +patch Structured Syntax Suffix .......................12
   5. Checking Capabilities ..........................................13
   6. Race Conditions ................................................14
   7. Security Considerations ........................................14
   8. Conventions ....................................................14
   9. Copyright Notice ...............................................14
   10. References ....................................................15
      10.1. Normative References .....................................15
      10.2. Informative References ...................................15




1.  Introduction

   This documents describes a uniform approach for expressing changes to
   state over HTTP.  It builds upon [RFC7233] and details how patches
   can be defined using range units, ranges, and content.  Any patch is
   expressed in the form:

     "range X in units Y of the data was replaced with content Z"

   Range units define how original content (being patched) should be
   parsed to obtain a region of the content which is being patched, and
   then how that region is replaced with new content.

2.  Range Patch

   [RFC7233] effectively already defines how a patch operating on byte
   units can be represented over HTTP, using Content-Range,
   Content-Type, and Content-Length HTTP headers.  Example:

      HTTP/1.1 206 Partial Content
      Date: Wed, 15 Nov 1995 06:25:24 GMT
      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
      Content-Range: bytes 21010-47021/47022
      Content-Length: 26012
      Content-Type: image/gif

      ... 26012 bytes of partial image data ...

   The same approach can be used to describe a range inside content
   interpreted not as bytes, but, for example, as JSON [RFC8259] or
   JSON-compatible structure.  We define such JSON range unit in
   Section 4.1.  For example, given the following JSON document:

      {"foo": {"bar": [
        {"some": "thing"},
        {"no": "thing"},
        {"mo": "re"},
        {"baz": {"1": {"two": "tree"}}}
      ]}}

   One might make the following request:

      GET /api/document/1 HTTP/1.1
      Host: example.com
      Accept: application/json
      Range: json=/foo/bar/3/baz




   And receive the following response:

      HTTP/1.1 206 Partial Content
      Date: Thu, 31 Oct 2019 07:51:08 GMT
      Last-Modified: Thu, 18 Oct 2019 17:44:39 GMT
      Content-Range: json /foo/bar/3/baz
      Content-Length: 22
      Content-Type: application/json

      {"1": {"two": "tree"}}

   [RFC7233] defines and allows a Range header only for the GET request
Show full document text