├── requirements.txt ├── package.json ├── LICENSE.md ├── .editorconfig ├── ietf.json ├── sf.json ├── README.md ├── Makefile ├── writeups ├── early-hints.md ├── http2-tls13.md ├── immutable.md ├── h3-websockets.md ├── expect-ct.md ├── cice.md ├── 5987bis.md ├── encrypted-ce.md ├── h2-websockets.md ├── auth-info.md ├── client-hints.md ├── 451.md ├── tunnel-protocol.md ├── opp-sec.md ├── alt-svc.md ├── binary-message.md ├── template.md ├── digest.md ├── zstd-window-size.md ├── alias-proxy-status.md └── compression-dictionary.md ├── .github ├── workflows │ ├── update.yml │ ├── archive.yml │ ├── ghpages.yml │ └── publish.yml └── CODEOWNERS ├── .gitignore ├── SUBMITTING.md ├── archive ├── draft-ietf-httpbis-origin-h3.md ├── draft-ietf-httpbis-http2-tls13.md ├── draft-ietf-httpbis-zstd-window-size.md ├── draft-ietf-httpbis-h3-websockets.md ├── draft-ietf-httpbis-immutable.md ├── draft-ietf-httpbis-header-structure.poc_parser.py ├── draft-ietf-httpbis-cdn-loop.md ├── draft-ietf-httpbis-cookie-prefixes.md ├── draft-ietf-httpbis-cookie-alone.md ├── draft-ietf-httpbis-legally-restricted-status.xml ├── draft-ietf-httpbis-early-hints.md ├── draft-ietf-httpbis-alias-proxy-status.md └── draft-ietf-httpbis-h2-websockets.md ├── draft-ietf-httpbis-cache-groups.md ├── draft-ietf-httpbis-incremental.md └── CONTRIBUTING.md /requirements.txt: -------------------------------------------------------------------------------- 1 | rfc-http-validate 2 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "dependencies": { 3 | "aasvg": "^0.3.2" 4 | } 5 | } -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/httpwg/http-extensions/blob/main/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | end_of_line = lf 5 | insert_final_newline = true 6 | indent_style = space 7 | charset = utf-8 8 | trim_trailing_whitespace = true 9 | max_line_length = 100 10 | 11 | [Makefile] 12 | indent_style = tab 13 | 14 | [*.md] 15 | indent_size = 2 16 | 17 | [*.xml] 18 | indent_size = 2 19 | -------------------------------------------------------------------------------- /ietf.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": "httpbis", 3 | "group_info": { 4 | "chairs": ["mnot", "tfpauly"], 5 | "email": "ietf-http-wg@w3.org", 6 | "type": "wg", 7 | "activity_exclude_labels": ["editorial"] 8 | }, 9 | "repo_type": "specs", 10 | "revisions_tagged": true, 11 | "activity_summary_to": ["group_email"] 12 | } 13 | -------------------------------------------------------------------------------- /sf.json: -------------------------------------------------------------------------------- 1 | { 2 | "variant-key": "list", 3 | "variants": "dict", 4 | "signature": "dict", 5 | "signature-input": "dict", 6 | "repr-digest": "dict", 7 | "content-digest": "dict", 8 | "want-repr-digest": "dict", 9 | "want-content-digest": "dict", 10 | "upload-offset": "item", 11 | "upload-complete": "item", 12 | "upload-draft-interop-version": "item", 13 | 14 | "x-dict": "dict", 15 | "x-list": "list", 16 | "x-list-a": "list", 17 | "x-list-b": "list", 18 | "example-list": "list", 19 | "example-dict": "dict", 20 | "example-integer": "item", 21 | "example-decimal": "item", 22 | "example-string": "item", 23 | "example-token": "item", 24 | "example-bytesequence": "item", 25 | "example-boolean": "item" 26 | } 27 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Draft HTTP Extension Specifications 4 | 5 | This is the working area for the [IETF HTTP Working Group](https://httpwg.org/)'s extensions to HTTP. See [our contribution guidelines](CONTRIBUTING.md) for information about how to participate. 6 | 7 | **Be aware that all contributions to our work fall under the "NOTE WELL" terms therein.** 8 | 9 | ![Editors' copies](https://github.com/httpwg/http-extensions/workflows/Update%20Editor's%20Copy/badge.svg) 10 | 11 | See the [list of specifications](https://httpwg.org/http-extensions/) with links to editors' drafts, document status, issues, and more information. 12 | 13 | Note that the HTTP Working Group develops documents in other repos; see [our repo list](https://github.com/httpwg/) and also the [official IETF list](https://datatracker.ietf.org/wg/httpbis/documents/) of WG documents. 14 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | INDEX_FORMAT := md 3 | GHPAGES_COMMIT_TTL = 7 4 | GHPAGES_BRANCH_TTL = 2 5 | 6 | 7 | include $(LIBDIR)/main.mk 8 | 9 | $(LIBDIR)/main.mk: 10 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 11 | git submodule sync 12 | git submodule update --init 13 | else 14 | ifneq (,$(wildcard $(ID_TEMPLATE_HOME))) 15 | ln -s "$(ID_TEMPLATE_HOME)" $(LIBDIR) 16 | else 17 | git clone -q --depth 10 -b main \ 18 | https://github.com/martinthomson/i-d-template $(LIBDIR) 19 | endif 20 | endif 21 | 22 | clean:: 23 | -rm -f .*.http-lint.txt 24 | 25 | lint:: http-lint 26 | 27 | rfc-http-validate ?= rfc-http-validate 28 | .SECONDARY: $(drafts_xml) 29 | .PHONY: http-lint 30 | http-lint: $(addsuffix .http-lint.txt,$(addprefix .,$(drafts))) 31 | .%.http-lint.txt: %.xml $(DEPS_FILES) 32 | $(trace) $< -s http-lint $(rfc-http-validate) -q -m sf.json $< 33 | @touch $@ 34 | -------------------------------------------------------------------------------- /writeups/early-hints.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-early-hints 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd. Alexey Melnikov is the responsible Area Director. 6 | 7 | This memo introduces an informational HTTP status code that can be used to convey hints that 8 | help a client make preparations for processing the final response. 9 | 10 | The Working Group has chosen Experimental to get deployment experience with this extension. 11 | 12 | 13 | ## 2. Review and Consensus 14 | 15 | This draft has enjoyed broad review from the Working Group, and a number of parties have expressed an intent to implement, or have already started. 16 | 17 | 18 | ## 3. Intellectual Property 19 | 20 | The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 21 | 22 | 23 | ## 4. Other Points 24 | 25 | N/A 26 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update Generated Files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update Files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v4 28 | 29 | - name: "Update Generated Files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Automatically generated CODEOWNERS 2 | # Regenerate with `make update-codeowners` 3 | draft-ietf-httpbis-cache-groups.md mnot@mnot.net 4 | draft-ietf-httpbis-compression-dictionary.md pmeenan@google.com yoav.weiss@shopify.com 5 | draft-ietf-httpbis-connect-tcp.md ietf@bemasc.net 6 | draft-ietf-httpbis-incremental.md kazuhooku@gmail.com tpauly@apple.com mt@lowentropy.net 7 | draft-ietf-httpbis-no-vary-search.md d@domenic.me jbroman@chromium.org 8 | draft-ietf-httpbis-optimistic-upgrade.md ietf@bemasc.net 9 | draft-ietf-httpbis-resumable-upload.md marius@transloadit.com guoye_zhang@apple.com lucas@lucaspardue.com 10 | draft-ietf-httpbis-retrofit.md mnot@mnot.net 11 | draft-ietf-httpbis-rfc6265bis.md bingler@google.com mkwst@google.com wilander@apple.com 12 | draft-ietf-httpbis-safe-method-w-body.xml julian.reschke@greenbytes.de malhotrasahib@gmail.com jasnell@gmail.com mbishop@evequefou.be 13 | draft-ietf-httpbis-secondary-server-certs.md e_gorbaty@apple.com mbishop@evequefou.be 14 | draft-ietf-httpbis-wrap-up.md dschinazi.ietf@gmail.com lucas@lucaspardue.com 15 | -------------------------------------------------------------------------------- /writeups/http2-tls13.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-http2-tls13 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the Document Shepherd; Barry Lieba is the responsible Area Director.0 6 | 7 | This document updates HTTP/2 to prohibit TLS 1.3 post-handshake authentication, as an analog to 8 | existing TLS 1.2 renegotiation restriction. 9 | 10 | Its intended status is Proposed Standard. 11 | 12 | ## 2. Review and Consensus 13 | 14 | This document was prepared when Working Group members noticed that the restrictions for post-handshake authentication in HTTP/2, which were designed with the constraints of TLS 1.2 in mind, no longer were necessary for TLS 1.3. 15 | 16 | Therefore, this is a very short update to address that. It has wide support amongst the working group, including from implementers. 17 | 18 | ## 3. Intellectual Property 19 | 20 | The author has confirmed that to their direct, personal knowledge, all IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 21 | 22 | ## 4. Other Points 23 | 24 | None. 25 | 26 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | inputs: 10 | archive_full: 11 | description: 'Recreate the archive from scratch' 12 | default: false 13 | type: boolean 14 | 15 | jobs: 16 | build: 17 | name: "Archive Issues and Pull Requests" 18 | runs-on: ubuntu-latest 19 | permissions: 20 | contents: write 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v4 24 | 25 | # Note: No caching for this build! 26 | 27 | - name: "Update Archive" 28 | uses: martinthomson/i-d-template@v1 29 | env: 30 | ARCHIVE_FULL: ${{ inputs.archive_full }} 31 | with: 32 | make: archive 33 | token: ${{ github.token }} 34 | 35 | - name: "Update GitHub Pages" 36 | uses: martinthomson/i-d-template@v1 37 | with: 38 | make: gh-archive 39 | token: ${{ github.token }} 40 | 41 | - name: "Save Archive" 42 | uses: actions/upload-artifact@v4 43 | with: 44 | path: archive.json 45 | -------------------------------------------------------------------------------- /writeups/immutable.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-immutable 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. 6 | 7 | The immutable HTTP response Cache-Control extension allows servers to identify resources that will 8 | not be updated during their freshness lifetime. This assures that a client never needs to 9 | revalidate a cached fresh resource to be certain it has not been modified. 10 | 11 | The requested publication type is Proposed Standard. 12 | 13 | 14 | ## 2. Review and Consensus 15 | 16 | This document quickly gained broad interest within the Working Group, and then support. It has been 17 | reviewed by a substantial number of participants, and implemented by Mozilla in Firefox, and by 18 | Facebook and others on the server side. Microsoft and Squid have stated that they are in the 19 | process of implementing. 20 | 21 | 22 | ## 3. Intellectual Property 23 | 24 | The author has stated that their direct, personal knowledge of any IPR related to this document 25 | has already been disclosed, in conformance with BCPs 78 and 79. 26 | 27 | 28 | ## 4. Other Points 29 | 30 | No other points. 31 | -------------------------------------------------------------------------------- /writeups/h3-websockets.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-h3-websockets 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd; Francesca Palombini is the responsible Area Director. 6 | 7 | The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. 8 | 9 | This document is being requested for publication as a Proposed Standard. 10 | 11 | 12 | ## 2. Review and Consensus 13 | 14 | Because it is both small and extending already established functionality from HTTP/2 to HTTP/3, this document has enjoyed brief but thorough review by the HTTP WG. Its progress has been uncontroversial, and considered an obvious but necessary step by all that have weighed in. 15 | 16 | 17 | ## 3. Intellectual Property 18 | 19 | The author has confirmed that they have stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 20 | 21 | 22 | ## 4. Other Points 23 | 24 | There are no downrefs in this document, and the IANA Considerations appear to be correct. 25 | 26 | The acknowledgements section is empty and can be removed in a subsequent draft, or by the RFC Editor. 27 | -------------------------------------------------------------------------------- /writeups/expect-ct.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-expect-ct 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd. Alexey Melnikov is the responsible Area Director. 6 | 7 | This document defines a new HTTP header field, named Expect-CT, that allows web host operators to 8 | instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on 9 | connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in 10 | their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs 11 | are discoverable in Certificate Transparency logs. 12 | 13 | ## 2. Review and Consensus 14 | 15 | This document did not see a tremendous amount of discussion after the Working Group agreed to adopt it, but did see a number of reviews from within the community. Given its intended status as Experimental, we believe this is appropriate. 16 | 17 | ## 3. Intellectual Property 18 | 19 | The author has confirmed that to her direct, personal knowledge, all IPR related to this document has already been disclosed. 20 | 21 | ## 4. Other Points 22 | 23 | The IANA considerations seem correct, except that the requested registry needs to be more specific - it will be a permanent registration. This will be corrected in the next revision (currently the submission queue is closed). 24 | -------------------------------------------------------------------------------- /writeups/cice.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-cice 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd; Barry Leiba is the responsible Area Director. 6 | 7 | In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages. 8 | 9 | Content codings can be used in request messages as well, however discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate that content codings are supported in requests. 10 | 11 | ## 2. Review and Consensus 12 | 13 | This document was discussed at a few meetings, as well as on the list. It was reviewed by a number of people, and a few different designs were discussed early in its lifetime before we settled on the current design. 14 | 15 | There is not currently any known implementation; this document is "filling a hole" in HTTP, and we 16 | have seem some interest from implementers and deployers of HTTP. 17 | 18 | ## 3. Intellectual Property 19 | 20 | Julian has confirmed that to his direct, personal knowledge, there is no IPR related to this document. 21 | 22 | ## 4. Other Points 23 | 24 | This document does not contain any downreferences, and its IANA considerations are clear. 25 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.html 2 | *.pdf 3 | *.redxml 4 | *.swp 5 | *.txt 6 | *.upload 7 | *~ 8 | .refcache 9 | .tags 10 | .targets.mk 11 | /*-[0-9][0-9].xml 12 | /.*.mk 13 | /.gems/ 14 | /.refcache 15 | /.venv/ 16 | /.vscode/ 17 | /lib 18 | /node_modules/ 19 | /versioned/ 20 | Gemfile.lock 21 | archive.json 22 | draft-ietf-httpbis-*.xml 23 | draft-ietf-httpbis-alias-proxy-status.xml 24 | draft-ietf-httpbis-cache-groups.xml 25 | draft-ietf-httpbis-client-cert-field.xml 26 | draft-ietf-httpbis-compression-dictionary.xml 27 | draft-ietf-httpbis-connect-tcp.xml 28 | draft-ietf-httpbis-digest-headers.xml 29 | draft-ietf-httpbis-incremental.xml 30 | draft-ietf-httpbis-message-signatures.xml 31 | draft-ietf-httpbis-no-vary-search.xml 32 | draft-ietf-httpbis-optimistic-upgrade.xml 33 | draft-ietf-httpbis-origin-h3.xml 34 | draft-ietf-httpbis-resumable-upload.xml 35 | draft-ietf-httpbis-retrofit.xml 36 | draft-ietf-httpbis-rfc6265bis.xml 37 | draft-ietf-httpbis-rfc7838bis.xml 38 | draft-ietf-httpbis-safe-method-w-body.xml 39 | draft-ietf-httpbis-secondary-server-certs.xml 40 | draft-ietf-httpbis-sfbis.xml 41 | draft-ietf-httpbis-unprompted-auth.xml 42 | draft-ietf-httpbis-variants.xml 43 | draft-ietf-httpbis-wrap-up.xml 44 | draft-ietf-httpbis-zstd-window-size.xml 45 | issues.json 46 | lib 47 | node_modules//lib 48 | package-lock.json 49 | pulls.json 50 | report.xml 51 | rfc9729.xml 52 | venv/ 53 | !draft-ietf-httpbis-safe-method-w-body.xml 54 | !requirements.txt 55 | -------------------------------------------------------------------------------- /writeups/5987bis.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for RFC5987bis 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the Document Shepherd. The responsible AD is Alexey Melnikov. 6 | 7 | By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry 8 | characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use 9 | in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This 10 | document specifies an encoding suitable for use in HTTP header fields that is compatible with a 11 | simplified profile of the encoding defined in RFC 2231. 12 | 13 | The intended status is Proposed Standard, unchanged from RFC5987. The Working Group felt that 14 | promoting it to full Internet Standard would be inappropriate. 15 | 16 | 17 | ## 2. Review and Consensus 18 | 19 | This is a bis document that seeks to revise a document the WG published in the past. Because of 20 | that, it has received attention and review from a small set of active WG members. However, none of 21 | the document changes are controversial. 22 | 23 | 24 | ## 3. Intellectual Property 25 | 26 | The author has confirmed that to their direct, personal knowlege, all IPR related to this document 27 | has already been disclosed. 28 | 29 | 30 | ## 4. Other Information 31 | 32 | Note that this draft has non-ASCII content in it, and therefore needs to be published using the 33 | new, Unicode-enabled process. -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | permissions: 22 | contents: write 23 | steps: 24 | - name: "Checkout" 25 | uses: actions/checkout@v4 26 | 27 | - name: "Setup" 28 | id: setup 29 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 30 | 31 | - name: "Caching" 32 | uses: actions/cache@v4 33 | with: 34 | path: | 35 | .refcache 36 | .venv 37 | .gems 38 | node_modules 39 | .targets.mk 40 | key: i-d-${{ steps.setup.outputs.date }} 41 | restore-keys: i-d- 42 | 43 | - name: "Build Drafts" 44 | uses: martinthomson/i-d-template@v1 45 | with: 46 | token: ${{ github.token }} 47 | 48 | - name: "Update GitHub Pages" 49 | uses: martinthomson/i-d-template@v1 50 | if: ${{ github.event_name == 'push' }} 51 | with: 52 | make: gh-pages 53 | token: ${{ github.token }} 54 | 55 | - name: "Archive Built Drafts" 56 | uses: actions/upload-artifact@v4 57 | with: 58 | path: | 59 | draft-*.html 60 | draft-*.txt 61 | -------------------------------------------------------------------------------- /writeups/encrypted-ce.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-encryption-encoding 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. 6 | 7 | This memo introduces a content-coding for HTTP that allows message payloads to 8 | be encrypted. 9 | 10 | The intended status is Proposed Standard. 11 | 12 | ## 2. Review and Consensus 13 | 14 | This document has been discussed for some time in the Working Group, going through several 15 | revisions and reviews. The editor is primarily responsible for the design, but reviews by a number 16 | of other people have shaped its design over time. 17 | 18 | The most immediate use case comes from the WEBPUSH WG. 19 | 20 | A list of implementations can be found at: 21 | https://github.com/httpwg/wiki/wiki/EncryptedContentEncoding 22 | Note that some need to be updated to reflect the latest draft. 23 | 24 | ## 3. Intellectual Property 25 | 26 | Martin has confirmed that, to his direct, personal knowledge, all IPR related to this document has 27 | already been disclosed, in conformance with BCPs 78 and 79. 28 | 29 | One IPR disclosure has been made for this document; see . 30 | The Working Group was informed of this (see 31 | ), but no changes to the draft 32 | resulted. 33 | 34 | ## 4. Other Points 35 | 36 | This document has a downward reference to RFC5869, which is already in the DOWNREF Registry. 37 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | workflow_dispatch: 8 | inputs: 9 | email: 10 | description: "Submitter email" 11 | default: "" 12 | type: string 13 | 14 | jobs: 15 | build: 16 | name: "Publish New Draft Version" 17 | runs-on: ubuntu-latest 18 | steps: 19 | - name: "Checkout" 20 | uses: actions/checkout@v4 21 | 22 | # See https://github.com/actions/checkout/issues/290 23 | - name: "Get Tag Annotations" 24 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 25 | 26 | - name: "Setup" 27 | id: setup 28 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 29 | 30 | - name: "Caching" 31 | uses: actions/cache@v4 32 | with: 33 | path: | 34 | .refcache 35 | .venv 36 | .gems 37 | node_modules 38 | .targets.mk 39 | key: i-d-${{ steps.setup.outputs.date }} 40 | restore-keys: i-d- 41 | 42 | - name: "Build Drafts" 43 | uses: martinthomson/i-d-template@v1 44 | with: 45 | token: ${{ github.token }} 46 | 47 | - name: "Upload to Datatracker" 48 | uses: martinthomson/i-d-template@v1 49 | with: 50 | make: upload 51 | env: 52 | UPLOAD_EMAIL: ${{ inputs.email }} 53 | 54 | - name: "Archive Submitted Drafts" 55 | uses: actions/upload-artifact@v4 56 | with: 57 | path: "versioned/draft-*-[0-9][0-9].*" 58 | -------------------------------------------------------------------------------- /writeups/h2-websockets.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-h2-websockets 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the Document Shepherd; Alexey Melnikov is the responsible Area Director. 6 | 7 | This document defines a mechanism for running the WebSocket Protocol over a single stream of an 8 | HTTP/2 connection. 9 | 10 | The intended publication type is Proposed Standard. 11 | 12 | ## 2. Review and Consensus 13 | 14 | This document enjoyed broad discussion and review in the HTTP Working Group; there seems to be 15 | significant community interest in it, since it enables the use of WebSockets on a HTTP/2 server, 16 | reducing operational issues for Web sites. 17 | 18 | Deployment depends upon implementation in Web browsers; at least one has already written code for 19 | this feature and is in process of shipping it. 20 | 21 | There was some concern about whether it was appropriate for a version-specific extension (a HTTP/2 22 | SETTING) to modify the semantics of a version-generic HTTP method (CONNECT), but the WG reached 23 | consensus that CONNECT is "special" in this regard. 24 | 25 | ## 3. Intellectual Property 26 | 27 | Patrick has confirmed that to his direct, personal knowledge, no IPR related to this document needs 28 | to be disclosed. 29 | 30 | ## 4. Other Points 31 | 32 | The document does not have any downrefs. 33 | 34 | IDNits points out some minor issues which will be addressed in a subsequent draft. 35 | 36 | The IANA Considerations are concise and correct. Note that 0x8 was chosen to avoid colliding with 37 | draft-ietf-httpbis-cache-digest. 38 | -------------------------------------------------------------------------------- /writeups/auth-info.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for auth-info 2 | 3 | ## 1. Summary 4 | 5 | The document shepherd is Mark Nottingham; the responsible Area Director is Barry Leiba. 6 | 7 | This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted. 8 | 9 | 10 | ## 2. Review and Consensus 11 | 12 | This document separates the definition of the "Authentication-Info" and "Proxy-Authentication-Info" HTTP header fields from RFC2617, so that they can be used by other HTTP authentication schemes (including some being actively developed). 13 | 14 | As such, the header fields have already enjoyed implementation and deployment; we have merely re-specified them for more generic use. Because other Working Groups depend upon this specification to progress their work items, we have done this work fairly quickly, but with care. 15 | 16 | The resulting specification has been reviewed by several Working Group members, and after a small amount of discussion, its content has been uncontroversial. 17 | 18 | 19 | ## 3. Intellectual Property 20 | 21 | Julian Reschke has confirmed that any IPR he's personally aware of related to this document has been disclosed. No other discussion of related IPR has taken place. 22 | 23 | 24 | ## 4. Other Points 25 | 26 | The document does not contain any downreferences. 27 | 28 | This document updates the IANA Message Headers registry, and contains clear instructions. It does not establish any new registries. 29 | -------------------------------------------------------------------------------- /writeups/client-hints.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-client-hints 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the Document Shepherd; Barry Lieba is the Responsible AD. 6 | 7 | An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. 8 | 9 | This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header field allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences. 10 | 11 | The intended status is Experimental, as there is currently only implementation in one major browser engine (Chromium, used in several browsers). The Working Group felt that it was useful to document this protocol extension to improve interoperability and encourage further implementation. 12 | 13 | ## 2. Review and Consensus 14 | 15 | The document was reviewed by a broad range of Working Group participants, as well as external parties (through Github and other external venues). Members of the Web performance optimisation community are especially interested in this specification, as it allows for automating the use of "responsive images." 16 | 17 | Consensus is rough regarding how useful this specification will be, but there was agreement that it was useful to document; hence the Experimental status. 18 | 19 | ## 3. Intellectual Property 20 | 21 | The authors confirm that to their direct, personal knowledge, all IPR related to this document has already been disclosed. 22 | 23 | 24 | ## 4. Other Points 25 | 26 | There are no downrefs. IANA Considerations are clear. 27 | 28 | -------------------------------------------------------------------------------- /writeups/451.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-legally-restricted-status 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd; Barry Leiba is the responsible Area Director. 6 | 7 | This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands. 8 | 9 | Its requested publication type is Proposed Standard. 10 | 11 | 12 | ## 2. Review and Consensus 13 | 14 | This document started as an individual draft, which the WG discussed and initially decided to "hold". The primary reason for this was that it wasn't clear if there were use cases that would benefit from a status code (as opposed to just using the body of the response), and whether there was interest in deployment. 15 | 16 | Over time, this was clarified; both Web sites and consuming software demonstrated interest. Importantly, we heard that having an indicator that an automated client could easily detect would help users like Lumen (formerly, Chilling Effects). 17 | 18 | As a result (and after discussion both on list and in meetings), we decided to adopt the draft. 19 | 20 | Technical discussion involved a broad selection of the Working Group. There was some back and forth about what the right scope for the status code's semantics should be (as well as whether we needed more than one), but we were able to achieve consensus on the current document. 21 | 22 | 451 has already been adopted by some sites on the Web, and based upon discussions (mostly private), it appears that a significantly larger number will adopt it once it becomes standard. On the client side, interest has been expressed by Lumen, Article19, CDT and others. 23 | 24 | 25 | ## 3. Intellectual Property 26 | 27 | The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 28 | 29 | -------------------------------------------------------------------------------- /writeups/tunnel-protocol.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for draft-ietf-httpbis-tunnel-protocol 2 | 3 | ## 1. Summary 4 | 5 | Mark Nottingham is the document shepherd; Barry Leiba is the responsible Area Director. 6 | 7 | This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the ALPN header field. 8 | 9 | Its intended status is Proposed Standard. 10 | 11 | ## 2. Review and Consensus 12 | 13 | This document was brought to the Working Group as a result of work in WebRTC and related groups, 14 | to satisfy a requirement there. 15 | 16 | It was discussed in WG meetings as well as on-list, with a broad selection of participants. 17 | 18 | Some participants were concerned that the mechanism is not verifiable; i.e., an intermediary does not have any assurance that the protocol in use inside an encrypted tunnel is actually advertised. However, we found that this is acceptable, because of the nature of the mechanism; it is not designed to provide such assurances, but instead allow coordination between cooperating (or semi-cooperating) actors. 19 | 20 | Other participants were concerned because of confusion about whether this mechanism can be used when TLS is not in use, and the ambiguity that the use of ALPN entails when it is not. We resolved this by explicitly linking it to ALPN, so that the protocol identifier can nominate whether encryption is in use. 21 | 22 | To our knowledge, this specification has not been implemented yet. This is not surprising, given the nature of the extension. 23 | 24 | 25 | ## 3. Intellectual Property 26 | 27 | Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed. 28 | 29 | No IPR declarations have been made. 30 | 31 | 32 | ## 4. Other Points 33 | 34 | Idnits reports a few problems, but they are spurious. 35 | 36 | IANA Considerations does not precisely identify the registry being entered into; the next draft will correct this. 37 | -------------------------------------------------------------------------------- /SUBMITTING.md: -------------------------------------------------------------------------------- 1 | # Working with the Drafts 2 | 3 | A few things to know if you're an editor: 4 | 5 | * Pushing to the master branch will automatically generate the HTML on the gh-pages branch. 6 | * Tagging master with a draft name (see below) will automatically submit it for publication. 7 | * Creating other branches for temporary work is fine, but please prefix their names with your username, and clean them up when you're done. 8 | * You can build drafts locally with `make`; see the [required software](https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md). We use `kramdown-rfc2669`. 9 | 10 | 11 | ## Starting a New Draft 12 | 13 | If you have been asked to start work on a new draft, you'll be given access to the repo. Once that happens, you'll need to: 14 | 15 | 1. Check in your draft using the `draft-ietf-httpbis-NAME.md` convention. We strongly recommend using Markdown; see the [template](https://github.com/martinthomson/i-d-template/blob/master/doc/example.md). 16 | 17 | 2. Assure that the document metadata is correct; if not sure, ask the Chairs. 18 | 19 | 3. Submit the draft, as per below. The `-00` version will need to be approved by the Chairs. 20 | 21 | 22 | ## Submitting A Draft Revision 23 | 24 | When you're ready to submit a new version of a draft: 25 | 26 | 0. `git status` <-- all changes should be committed and pushed. 27 | 28 | 1. Double-check the year on the date element to make sure it's current. 29 | 30 | 2. Check the "Changes" section for this draft to make sure it's appropriate 31 | (e.g., replace "None yet" with "None"). 32 | 33 | 3. `git tag -a draft-ietf-httpbis--NN;` 34 | `git push --tags` 35 | 36 | 4. Add "Since draft-ietf-httpbis--...-NN" subsection to "Changes" (if tracking them). 37 | 38 | Note: This process requires that the email address used to author the tag in step 3 matches an active IETF account. To that it, it might be necessary to configure the email address used for commits to this repository via `git config --local user.email mail@huzzah.example`. 39 | -------------------------------------------------------------------------------- /writeups/opp-sec.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for HTTP Opportunistic Security 2 | 3 | ## 1. Summary 4 | 5 | Mike Bishop is the document shepherd; Alexey Melnikov is the responsible Area 6 | Director. 7 | 8 | This document presents an experimental way to use 9 | [Alt-Svc](https://tools.ietf.org/html/rfc7838) to achieve opportunistic 10 | encryption connections to http:// schemed resources. While this does not offer 11 | the true security guarantees of the https:// scheme, it does improve resistance 12 | to passive surveillance by requiring some minimal level of active attack to 13 | defeat. 14 | 15 | ## 2. Review and Consensus 16 | 17 | The document has been closely reviewed and discussed by a small number of vocal 18 | participants, with a larger number of other participants adding occasional 19 | feedback. The community is generally divided about the utility of providing a 20 | tool which is so easily defeated by an active attacker, but there have been very 21 | few who believe this experiment would be detrimental. The primary concern voiced 22 | by dissenters has been that widespread deployment might provide a false sense of 23 | security, slowing the adoption of "real" HTTPS or confusing users. The 24 | restriction in section 4.1 was added to help mitigate this concern. 25 | 26 | RFC 7838 requires "reasonable assurances" that the alternative was under the 27 | control of the same authority as the origin. RFC 7838 defines only one means of 28 | having such assurance: possession of a TLS certificate for the origin. After 29 | much discussion, this draft maintains that definition and requires the use of 30 | fully verified certificates. 31 | 32 | The other item of particular concern around using RFC7838 with http:// URIs was 33 | server support for receiving requests for http:// schemed resources on ports 34 | configured to use TLS. While HTTP/1.1 might permit and HTTP/2 mandates the 35 | inclusion of the URL scheme with the request, it appears that almost no server 36 | implementations treat the included scheme as more authoritative than the port on 37 | which it was received. This is noted in section 4.4. As a result, the final 38 | version of this document prohibits the use of HTTP/1.1 and uses the .well-known 39 | resource as a server's self-certification that it can correctly distinguish such 40 | requests. 41 | 42 | A primary learning from experimentation with this draft will be to what degree 43 | this server behavior presents a deployment issue in the real world, and the 44 | degree to which servers will incorrectly claim this capability. 45 | 46 | There is a client implementation in Mozilla Firefox, though other browsers have 47 | expressed limited interest at this time. No explicit implementation of this 48 | draft is required in server software (the necessary resources and headers can be 49 | administratively configured). 50 | 51 | 52 | ## 3. Intellectual Property 53 | 54 | Each author has stated that their direct, personal knowledge of any IPR related 55 | to this document has already been disclosed, in conformance with BCPs 78 and 79. 56 | No IPR disclosures have been submitted regarding this document. 57 | 58 | ## 4. Other Points 59 | 60 | There are no downward references. The IANA Considerations are clear, and the 61 | Expert Reviewer for the affected registry is an author of this draft. 62 | -------------------------------------------------------------------------------- /writeups/alt-svc.md: -------------------------------------------------------------------------------- 1 | # Shepherd Writeup for Alt-Svc 2 | 3 | ## 1. Summary 4 | 5 | Mike Bishop is the document shepherd; Barry Leiba is the responsible 6 | Area Director. 7 | 8 | This document specifies a method to provide clients authoritative access 9 | to HTTP origins at a different network location and/or using a different 10 | protocol stack. 11 | 12 | The requested publication type is Proposed Standard. 13 | 14 | ## 2. Review and Consensus 15 | 16 | The document started as an individual draft which provided a potential 17 | solution to several related problems in the HTTP space, helping clients 18 | become aware of multiple network or protocol endpoints for an origin 19 | that could serve the same content in different ways. It drew inspiration 20 | from an existing proprietary solution, Alternate-Protocol, used by 21 | Chromium during SPDY development. 22 | 23 | There was implementation interest from Mozilla Firefox and Akamai, along 24 | with willingness from Google Chrome to migrate from Alternate-Protocol 25 | to Alt-Svc. Other implementers were less interested, but as the behavior 26 | is fully optional for clients, the consensus was to adopt the document. 27 | During the HTTP/2 standardization process, the Alt-Svc document was 28 | discussed and worked on in parallel; HTTP/2-specific pieces were 29 | originally added to the HTTP/2 specification at the time of adoption, 30 | but were moved into this document after HTTP/2's extension story was 31 | agreed upon. 32 | 33 | There has been some interest in defining additional ways to discover 34 | Alternative Services, and this document intentionally does not close the 35 | door on that. It discusses client behavior when dealing with 36 | Alternatives of which it is aware, and defines two possible ways a 37 | client can learn about Alternatives. Future drafts may define additional 38 | ways, such as DNS. 39 | 40 | Technical discussions involved a broad section of the working group, 41 | with the most focus from a few client and proxy implementers. There has 42 | been some back and forth about the right balance between utility and 43 | security, but the document now reflects general consensus. This is 44 | reflected by a thoroughly-discussed Security Considerations section, 45 | which covers ways in which Alt-Svc could be used to track clients or 46 | persist attacks, and gives guidance to implementations on ways to 47 | minimize the potential impacts. 48 | 49 | ## 3. Intellectual Property 50 | 51 | Each author has stated that their direct, personal knowledge of any IPR 52 | related to this document has already been disclosed, in conformance with 53 | BCPs 78 and 79. 54 | 55 | No disclosures have been submitted regarding prior work in this space. 56 | 57 | ## 4. Other Points 58 | 59 | There are no downward references. The IANA Considerations are clear, and 60 | the Expert Reviewers for the existing registries have been actively 61 | involved in the draft process. A new registry is also created for 62 | parameters modifying properties of Alt-Svc listings. 63 | 64 | There was some discussion over whether parameters would be 65 | mandatory-to-understand (ignoring the entire entry otherwise), or always 66 | optional. In the end, parameters were made optional-to-understand in all 67 | cases, to avoid exploding the list of alternatives when multiple 68 | optional parameters were used. 69 | 70 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-origin-h3.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: The ORIGIN Extension in HTTP/3 3 | abbrev: ORIGIN in HTTP/3 4 | number: 9412 5 | docname: draft-ietf-httpbis-origin-h3-latest 6 | date: 2023-06 7 | category: std 8 | 9 | ipr: trust200902 10 | area: Applications and Real-Time 11 | workgroup: HTTPbis 12 | keyword: Internet-Draft 13 | 14 | stand_alone: yes 15 | pi: [toc, sortrefs, symrefs] 16 | 17 | author: 18 | - 19 | ins: M. Bishop 20 | name: Mike Bishop 21 | organization: Akamai 22 | email: mbishop@evequefou.be 23 | 24 | normative: 25 | RFC9113: 26 | display: HTTP/2 27 | RFC9114: 28 | display: HTTP/3 29 | 30 | informative: 31 | QUIC-TRANSPORT: 32 | RFC9000 33 | 34 | 35 | --- abstract 36 | 37 | The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it 38 | needs to be separately registered. This document describes the ORIGIN 39 | frame for HTTP/3. 40 | 41 | --- middle 42 | 43 | # Introduction {#problems} 44 | 45 | Existing RFCs define extensions to HTTP/2 {{RFC9113}} that remain useful in 46 | HTTP/3. {{Section A.2 of RFC9114}} describes the required updates for HTTP/2 47 | frames to be used with HTTP/3. 48 | 49 | {{!ORIGIN=RFC8336}} defines the HTTP/2 ORIGIN frame, which indicates what 50 | origins are available on a given connection. It defines a single HTTP/2 frame 51 | type. 52 | 53 | ## Notational Conventions 54 | 55 | {::boilerplate bcp14-tagged} 56 | 57 | The frame diagram in this document uses the format defined in {{Section 1.3 of 58 | QUIC-TRANSPORT}} to illustrate the order and size of fields. 59 | 60 | # The ORIGIN HTTP/3 Frame {#frame-origin} 61 | 62 | The ORIGIN HTTP/3 frame allows a server to indicate what origin or origins 63 | {{?RFC6454}} the server would like the client to consider as one or more members 64 | of the Origin Set ({{Section 2.3 of ORIGIN}}) for the connection within which it 65 | occurs. 66 | 67 | The semantics of the frame payload are identical to those of the HTTP/2 frame 68 | defined in {{!ORIGIN}}. Where HTTP/2 reserves stream 0 for frames related to the 69 | state of the connection, HTTP/3 defines a pair of unidirectional streams called 70 | "control streams" for this purpose. 71 | 72 | Where {{ORIGIN}} indicates that the ORIGIN frame is sent on stream 0, this 73 | should be interpreted to mean the HTTP/3 control stream: that is, 74 | the ORIGIN frame is sent from servers to clients on the server's control stream. 75 | 76 | HTTP/3 does not define a Flags field in the generic frame layout. As no flags 77 | have been defined for the ORIGIN frame, this specification does not define a 78 | mechanism for communicating such flags in HTTP/3. 79 | 80 | ## Frame Layout 81 | 82 | The ORIGIN frame has a layout that is nearly identical to the 83 | layout used in HTTP/2; the information is restated here for clarity. The ORIGIN 84 | frame type is 0x0c (decimal 12), as in HTTP/2. The payload contains zero or more 85 | instances of the Origin-Entry field. 86 | 87 | ~~~~~ ascii-art 88 | HTTP/3 Origin-Entry { 89 | Origin-Len (16), 90 | ASCII-Origin (..), 91 | } 92 | 93 | HTTP/3 ORIGIN Frame { 94 | Type (i) = 0x0c, 95 | Length (i), 96 | Origin-Entry (..) ..., 97 | } 98 | ~~~~~ 99 | {: title="ORIGIN Frame Layout"} 100 | 101 | An Origin-Entry is a length-delimited string. Specifically, it contains two 102 | fields: 103 | 104 | Origin-Len: 105 | : An unsigned, 16-bit integer indicating the length, in octets, of 106 | the ASCII-Origin field. 107 | 108 | ASCII-Origin: 109 | : An OPTIONAL sequence of characters containing the ASCII serialization of an 110 | origin ({{RFC6454, Section 6.2}}) that the sender asserts this connection is 111 | or could be authoritative for. 112 | 113 | # Security Considerations {#security} 114 | 115 | This document introduces no new security considerations beyond those discussed 116 | in {{!ORIGIN}} and {{RFC9114}}. 117 | 118 | # IANA Considerations {#iana} 119 | 120 | This document registers a frame type in the "HTTP/3 Frame Types" registry 121 | defined by {{RFC9114}}, located at 122 | \. 123 | 124 | Value: 125 | : 0x0c 126 | 127 | Frame Type: 128 | : ORIGIN 129 | 130 | Status: 131 | : permanent 132 | 133 | Reference: 134 | : {{frame-origin}} 135 | 136 | Date: 137 | : 2023-03-14 138 | 139 | Change Controller: 140 | : IETF 141 | 142 | Contact: 143 | : HTTP WG \ 144 | 145 | --- back 146 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-http2-tls13.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Using TLS 1.3 with HTTP/2 3 | docname: draft-ietf-httpbis-http2-tls13-latest 4 | category: std 5 | updates: 7540 6 | 7 | ipr: trust200902 8 | area: Applications and Real-Time 9 | workgroup: HTTP 10 | 11 | pi: [toc, sortrefs, symrefs] 12 | stand_alone: yes 13 | 14 | author: 15 | - 16 | ins: D. Benjamin 17 | name: David Benjamin 18 | organization: Google LLC 19 | email: davidben@google.com 20 | 21 | normative: 22 | RFC2119: 23 | RFC5246: 24 | RFC7230: 25 | RFC7301: 26 | RFC7540: 27 | RFC8446: 28 | 29 | informative: 30 | RFC8470: 31 | 32 | 33 | --- abstract 34 | 35 | This document updates RFC 7540 by forbidding TLS 1.3 post-handshake 36 | authentication, as an analog to the existing TLS 1.2 renegotiation restriction. 37 | 38 | --- note_Note_to_Readers 39 | 40 | *RFC EDITOR: please remove this section before publication* 41 | 42 | Discussion of this draft takes place on the HTTP working group mailing list 43 | (ietf-http-wg@w3.org), which is archived at . 44 | 45 | Working Group information can be found at ; source 46 | code and issues list for this draft can be found at 47 | . 48 | 49 | --- middle 50 | 51 | # Introduction 52 | 53 | TLS 1.2 {{RFC5246}} and earlier versions of TLS support renegotiation, a 54 | mechanism for changing 55 | parameters and keys partway through a connection. This was sometimes used to 56 | implement reactive client authentication in HTTP/1.1 {{RFC7230}}, where the 57 | server decides whether or not to request a client certificate based on the HTTP 58 | request. 59 | 60 | HTTP/2 {{RFC7540}} multiplexes multiple HTTP requests over a single connection, 61 | which is incompatible with the mechanism above. Clients cannot correlate the 62 | certificate request with the HTTP request that triggered it. Thus, Section 63 | 9.2.1 of {{RFC7540}} forbids renegotiation. 64 | 65 | TLS 1.3 {{RFC8446}} removes renegotiation and replaces it with separate 66 | post-handshake authentication and key update mechanisms. Post-handshake 67 | authentication has the same problems with multiplexed protocols as TLS 1.2 68 | renegotiation, but the prohibition in {{RFC7540}} 69 | only applies to renegotiation. 70 | 71 | This document updates HTTP/2 {{RFC7540}} to similarly forbid TLS 1.3 post-handshake 72 | authentication. 73 | 74 | 75 | # Requirements Language 76 | 77 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 78 | "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 79 | document are to be interpreted as described in BCP 14 {{RFC2119}} {{!RFC8174}} 80 | when, and only when, they appear in all capitals, as shown here. 81 | 82 | 83 | # Post-Handshake Authentication in HTTP/2 84 | 85 | HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages. 86 | HTTP/2 clients MUST treat such messages as connection errors (see Section 5.4.1 87 | of {{RFC7540}}) of type PROTOCOL\_ERROR. 88 | 89 | {{RFC7540}} permitted renegotiation before the HTTP/2 connection preface to 90 | provide confidentiality of the client certificate. TLS 1.3 encrypts the client 91 | certificate in the initial handshake, so this is no longer necessary. HTTP/2 92 | servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages before 93 | the connection preface. 94 | 95 | The above applies even if the client offered the `post_handshake_auth` TLS 96 | extension. This extension is advertised independently of the selected 97 | Application-Layer Protocol Negotiation (ALPN) 98 | protocol {{RFC7301}}, so it is not sufficient to resolve the conflict with 99 | HTTP/2. HTTP/2 clients that also offer other ALPN protocols, notably HTTP/1.1, 100 | in a TLS ClientHello MAY include the `post_handshake_auth` extension to support 101 | those other protocols. This does not indicate support in HTTP/2. 102 | 103 | 104 | # Other Post-Handshake TLS Messages in HTTP/2 105 | 106 | {{RFC8446}} defines two other messages that are exchanged after the handshake is 107 | complete: KeyUpdate and NewSessionTicket. 108 | 109 | KeyUpdate messages only affect TLS itself and do not require any interaction 110 | with the application protocol. HTTP/2 implementations MUST support key updates 111 | when TLS 1.3 is negotiated. 112 | 113 | NewSessionTicket messages are also permitted. Though these interact with HTTP 114 | when early data is enabled, these interactions are defined in {{RFC8470}} and 115 | are allowed for in the design of HTTP/2. 116 | 117 | Unless the use of a new type of TLS message depends on an interaction with the 118 | application-layer protocol, that TLS message can be sent after the handshake 119 | completes. 120 | 121 | 122 | # Security Considerations 123 | 124 | This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when 125 | supporting post-handshake authentication with HTTP/1.1. This lowers the barrier 126 | for deploying TLS 1.3, a major security improvement over TLS 1.2. 127 | 128 | 129 | # IANA Considerations 130 | 131 | This document has no IANA actions. 132 | 133 | --- back 134 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-zstd-window-size.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Window Sizing for Zstandard Content Encoding 3 | abbrev: Zstd Window Size 4 | category: info 5 | 6 | docname: draft-ietf-httpbis-zstd-window-size-latest 7 | submissiontype: IETF 8 | number: 9 | date: 10 | consensus: true 11 | updates: 8878 12 | v: 3 13 | area: Web and Internet Transport 14 | workgroup: HTTPBIS 15 | keyword: 16 | - zstd 17 | - zstandard 18 | - compression 19 | - content encoding 20 | - content coding 21 | - application/zstd 22 | venue: 23 | group: HTTP 24 | type: Working Group 25 | mail: ietf-http-wg@w3.org 26 | arch: https://lists.w3.org/Archives/Public/ietf-http-wg/ 27 | github: httpwg/http-extensions/labels/zstd-window-size 28 | latest: "https://httpwg.org/http-extensions/draft-ietf-httpbis-zstd-window-size.html" 29 | github-issue-label: zstd-window-size 30 | 31 | author: 32 | - 33 | ins: N. Jaju 34 | fullname: Nidhi Jaju 35 | role: editor 36 | organization: Google 37 | street: Shibuya Stream, 3 Chome-21-3 Shibuya 38 | region: Shibuya City, Tokyo 39 | code: 150-0002 40 | country: Japan 41 | email: nidhijaju@google.com 42 | - 43 | ins: F. Handte 44 | fullname: W. Felix P. Handte 45 | role: editor 46 | organization: Meta Platforms, Inc. 47 | street: 380 W 33rd St 48 | city: New York 49 | region: NY 50 | code: 10001 51 | country: US 52 | email: felixh@meta.com 53 | 54 | normative: 55 | 56 | informative: 57 | 58 | 59 | --- abstract 60 | 61 | Deployments of Zstandard, or "zstd", can use different window sizes to limit 62 | memory usage during compression and decompression. Some browsers and user 63 | agents limit window sizes to mitigate memory usage concerns, causing 64 | interoperability issues. This document updates the window size limit in RFC8878 65 | from a recommendation to a requirement in HTTP contexts. 66 | 67 | 68 | --- middle 69 | 70 | # Introduction 71 | 72 | Zstandard, or "zstd", specified in {{?RFC8878}}, is a lossless data compression 73 | mechanism similar to gzip. When used with HTTP, the "zstd" content coding 74 | token signals to the decoder that the content is Zstandard-compressed. 75 | 76 | An important property of Zstandard-compressed content is its Window_Size 77 | ({{!RFC8878, Section 3.1.1.1.2}}), which describes the maximum distance for 78 | back-references and therefore how much of the content must be kept in memory 79 | during decompression. 80 | 81 | The minimum Window_Size is 1 KB. The maximum Window_Size is 82 | (1<<41) + 7*(1<<38) bytes, which is 3.75 TB. Larger Window_Size values tend 83 | to improve the compression ratio, but at the cost of increased memory usage. 84 | 85 | To protect against unreasonable memory usage, some browsers and user agents 86 | limit the maximum Window_Size they will handle. This causes failures to decode 87 | responses when the content is compressed with a larger Window_Size than the 88 | recipient allows, leading to decreased interoperability. 89 | 90 | {{!RFC8878, Section 3.1.1.1.2}} recommends that decoders support a Window_Size 91 | of up to 8 MB, and that encoders not generate frames using a Window_Size larger 92 | than 8 MB. However, it imposes no requirements. 93 | 94 | This document updates {{RFC8878}} to enforce Window_Size limits on the encoder 95 | and decoder for the "zstd" HTTP content coding. 96 | 97 | 98 | # Conventions and Definitions 99 | 100 | {::boilerplate bcp14-tagged} 101 | 102 | # Window Size 103 | 104 | To ensure interoperability, when using the "zstd" content coding, decoders MUST 105 | support a Window_Size of up to and including 8 MB, and encoders MUST NOT 106 | generate frames requiring a Window_Size larger than 8 MB (see 107 | {{zstd-iana-token}}). 108 | 109 | # Security Considerations 110 | 111 | This document introduces no new security considerations beyond those discussed 112 | in {{RFC8878}}. 113 | 114 | Note that decoders still need to take into account that they can receive 115 | oversized frames that do not follow the window size limit specified in this 116 | document and fail decoding when such invalid frames are received. 117 | 118 | # IANA Considerations 119 | 120 | ## Content Encoding {#zstd-iana-token} 121 | 122 | This document updates the entry added in {{RFC8878}} to the ["HTTP Content 123 | Coding Registry"](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding) 124 | within the ["Hypertext Transfer Protocol (HTTP) 125 | Parameters"](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml) 126 | registry: 127 | 128 | Name: 129 | 130 | : zstd 131 | 132 | Description: 133 | 134 | : A stream of bytes compressed using the Zstandard protocol with a Window_Size 135 | of not more than 8 MB. 136 | 137 | Reference: 138 | 139 | : This document and {{RFC8878}} 140 | 141 | 142 | --- back 143 | 144 | # Acknowledgments 145 | {:numbered="false"} 146 | 147 | Zstandard was developed by Yann Collet. 148 | 149 | The authors would like to thank Yann Collet, Klaus Post, Adam Rice, and members 150 | of the Web Performance Working Group in the W3C for collaborating on the window 151 | size issue and helping to formulate a solution. Also, thank you to Nick Terrell 152 | for providing feedback that went into RFC 8478 and RFC 8878. 153 | 154 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-h3-websockets.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Bootstrapping WebSockets with HTTP/3" 3 | number: 9220 4 | docname: draft-ietf-httpbis-h3-websockets-latest 5 | submissiontype: IETF 6 | consensus: true 7 | area: Transport 8 | category: std 9 | 10 | ipr: trust200902 11 | area: ART 12 | workgroup: HTTP 13 | keyword: 14 | - extended connect 15 | - 42 16 | venue: 17 | group: HTTP 18 | type: Working Group 19 | home: https://httpwg.org/ 20 | mail: ietf-http-wg@w3.org 21 | arch: https://lists.w3.org/Archives/Public/ietf-http-wg/ 22 | repo: https://github.com/httpwg/http-extensions/labels/h3-websockets 23 | github-issue-label: h3-websockets 24 | stand_alone: yes 25 | smart_quotes: no 26 | pi: [toc, sortrefs, symrefs] 27 | 28 | author: 29 | - 30 | name: Ryan Hamilton 31 | organization: Google 32 | email: rch@google.com 33 | 34 | normative: 35 | 36 | HTTP: 37 | title: "HTTP Semantics" 38 | date: 2022-04 39 | seriesinfo: 40 | RFC: 9110 41 | DOI: 10.17487/RFC9110 42 | author: 43 | - 44 | ins: R. Fielding 45 | name: Roy T. Fielding 46 | org: Adobe 47 | role: editor 48 | - 49 | ins: M. Nottingham 50 | name: Mark Nottingham 51 | org: Fastly 52 | role: editor 53 | - 54 | ins: J. Reschke 55 | name: Julian Reschke 56 | org: greenbytes 57 | role: editor 58 | 59 | HTTP2: 60 | display: HTTP/2 61 | title: "HTTP/2" 62 | date: 2022-04 63 | seriesinfo: 64 | RFC: 9113 65 | DOI: 10.17487/RFC9113 66 | author: 67 | - 68 | fullname: Martin Thomson 69 | org: Mozilla 70 | role: editor 71 | - 72 | fullname: Cory Benfield 73 | org: Apple Inc. 74 | role: editor 75 | 76 | HTTP3: 77 | display: HTTP/3 78 | title: "Hypertext Transfer Protocol Version 3 (HTTP/3)" 79 | date: 2022-04 80 | seriesinfo: 81 | RFC: 9114 82 | DOI: 10.17487/RFC9114 83 | author: 84 | - 85 | ins: M. Bishop 86 | name: Mike Bishop 87 | org: Akamai 88 | role: editor 89 | 90 | informative: 91 | 92 | 93 | --- abstract 94 | 95 | The mechanism for running the WebSocket Protocol over a single stream 96 | of an HTTP/2 connection is equally applicable to HTTP/3, but the 97 | HTTP-version-specific details need to be specified. This document describes 98 | how the mechanism is adapted for HTTP/3. 99 | 100 | --- middle 101 | 102 | # Introduction 103 | 104 | "Bootstrapping WebSockets with HTTP/2" {{!RFC8441}} defines an extension 105 | to HTTP/2 {{HTTP2}} that is also useful in HTTP/3 {{HTTP3}}. 106 | This extension makes use of an HTTP/2 setting. {{Appendix A.3 of HTTP3}} 107 | gives some guidance on what changes (if any) are appropriate when porting 108 | settings from HTTP/2 to HTTP/3. 109 | 110 | 111 | # Conventions and Definitions 112 | 113 | {::boilerplate bcp14-tagged} 114 | 115 | # WebSockets Upgrade over HTTP/3 116 | 117 | {{!RFC8441}} defines a mechanism for running the WebSocket Protocol 118 | {{!RFC6455}} over a single stream of an HTTP/2 connection. It defines 119 | an Extended CONNECT method that specifies a new ":protocol" 120 | pseudo-header field and new semantics for the ":path" and ":authority" 121 | pseudo-header fields. It also defines a new HTTP/2 setting sent by a server to 122 | allow the client to use Extended CONNECT. 123 | 124 | The semantics of the pseudo-header fields and setting are identical to those 125 | in HTTP/2 as defined in {{!RFC8441}}. {{Appendix A.3 of HTTP3}} requires that 126 | HTTP/3 settings be registered separately for HTTP/3. The 127 | SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. 128 | 129 | If a server advertises support for Extended CONNECT but receives an 130 | Extended CONNECT request with a ":protocol" value that is unknown or is 131 | not supported, the server SHOULD respond to the request with a 501 (Not 132 | Implemented) status code ({{Section 15.6.2 of HTTP}}). A server MAY 133 | provide more information via a "problem details" response {{!RFC7807}}. 134 | 135 | The HTTP/3 stream closure is also analogous to the TCP connection 136 | closure of {{!RFC6455}}. Orderly TCP-level closures are represented as 137 | a FIN bit on the stream ({{Section 4.2 of HTTP3}}). RST exceptions are 138 | represented with a stream error ({{Section 8 of HTTP3}}) of type 139 | H3_REQUEST_CANCELLED ({{Section 8.1 of HTTP3}}). 140 | 141 | # Security Considerations 142 | 143 | This document introduces no new security considerations beyond those 144 | discussed in {{!RFC8441}}. 145 | 146 | # IANA Considerations 147 | 148 | This document registers a new setting in the "HTTP/3 Settings" 149 | registry ({{Section 11.2.2 of HTTP3}}). 150 | 151 | Value: 152 | : 0x08 153 | 154 | Setting Name: 155 | : SETTINGS_ENABLE_CONNECT_PROTOCOL 156 | 157 | Default: 158 | : 0 159 | 160 | Status: 161 | : permanent 162 | 163 | Specification: 164 | : This document 165 | 166 | Change Controller: 167 | : IETF 168 | 169 | Contact: 170 | : HTTP Working Group (ietf-http-wg@w3.org) 171 | 172 | --- back 173 | 174 | # Acknowledgments 175 | {:numbered="false"} 176 | 177 | This document had reviews and input from many contributors in the IETF HTTP 178 | and QUIC Working Groups, with substantive input from David Schinazi, Martin 179 | Thomson, Lucas Pardue, Mike Bishop, Dragana Damjanovic, Mark Nottingham, and 180 | Julian Reschke. 181 | -------------------------------------------------------------------------------- /writeups/binary-message.md: -------------------------------------------------------------------------------- 1 | # Document Shepherd Writeup 2 | 3 | ## Document History 4 | 5 | Answer either of the two options below (depending on the document type), then continue with the common part. 6 | 7 | ### Option 1: For Documents Coming from IETF Working Groups 8 | 9 | 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? 10 | 11 | The document enjoyed reasonably wide review and discussion throughout the group. It was not a particularly active discussion, but a variety of folks appear to have looked at it and thought about it. 12 | 13 | 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 14 | 15 | No. 16 | 17 | 18 | ## Common Part 19 | 20 | 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 21 | 22 | No. 23 | 24 | 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942](https://www.rfc-editor.org/rfc/rfc7942.html) recommends) or elsewhere (where)? 25 | 26 | Yes - see datatracker. 27 | 28 | 29 | ### Additional Reviews 30 | 31 | 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? 32 | 33 | No. 34 | 35 | 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 36 | 37 | The document defines one media type that will require review. 38 | 39 | 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools](https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342](https://www.rfc-editor.org/rfc/rfc8342.html)? 40 | 41 | Not applicable. 42 | 43 | 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. 44 | 45 | Not applicable. 46 | 47 | 48 | ### Document Shepherd Checks 49 | 50 | 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? 51 | 52 | Yes. 53 | 54 | 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter](https://trac.ietf.org/trac/iesg/wiki/ExpertTopics). Do any such issues remain that would merit specific attention from subsequent reviews? 55 | 56 | Of the listed topics, this draft involves HTTP. 57 | 58 | 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? 59 | 60 | Proposed Standard. Because it's likely to be referenced by OHAI documents, and it has WG consensus. Yes, the datatracker appears to reflect that intent. 61 | 62 | 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78](https://www.rfc-editor.org/info/bcp78) and [BCP 79](https://www.rfc-editor.org/info/bcp79) have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. 63 | 64 | The author has confirmed that no IPR exists to his knowledge. 65 | 66 | 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. 67 | 68 | It's Martin's document, so I believe so. 69 | 70 | 14. Identify any remaining I-D nits in this document. (See [the idnits tool](http://www.ietf.org/tools/idnits/) and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. 71 | 72 | I-D nits flags several issues, but none seem germane. 73 | 74 | 15. Should any informative references be normative or vice-versa? 75 | 76 | They are all now correct, I believe. 77 | 78 | 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 79 | 80 | None. 81 | 82 | 17. Are there any normative downward references (see [RFC 3967](https://www.rfc-editor.org/rfc/rfc3967.html), [BCP 97](https://www.rfc-editor.org/info/bcp97))? If so, list them. 83 | 84 | No. 85 | 86 | 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? 87 | 88 | There are a number of references in the RFC Editor Queue, all in AUTH48 or beyond. 89 | 90 | 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. 91 | 92 | No. 93 | 94 | 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126](https://www.rfc-editor.org/rfc/rfc8126.html)). 95 | 96 | The document registers one new media type, and appears to do so correctly. 97 | 98 | 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. 99 | 100 | Not applicable. 101 | -------------------------------------------------------------------------------- /writeups/template.md: -------------------------------------------------------------------------------- 1 | # Document Shepherd Write-Up for Group Documents 2 | 3 | *This version is dated 4 July 2022.* 4 | 5 | Thank you for your service as a document shepherd. Among the responsibilities is 6 | answering the questions in this write-up to give helpful context to Last Call 7 | and Internet Engineering Steering Group ([IESG][1]) reviewers, and your 8 | diligence in completing it is appreciated. The full role of the shepherd is 9 | further described in [RFC 4858][2]. You will need the cooperation of the authors 10 | and editors to complete these checks. 11 | 12 | Note that some numbered items contain multiple related questions; please be sure 13 | to answer all of them. 14 | 15 | ## Document History 16 | 17 | 1. Does the working group (WG) consensus represent the strong concurrence of a 18 | few individuals, with others being silent, or did it reach broad agreement? 19 | 20 | 2. Was there controversy about particular points, or were there decisions where 21 | the consensus was particularly rough? 22 | 23 | 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If 24 | so, please summarize the areas of conflict in separate email messages to the 25 | responsible Area Director. (It should be in a separate email because this 26 | questionnaire is publicly available.) 27 | 28 | 4. For protocol documents, are there existing implementations of the contents of 29 | the document? Have a significant number of potential implementers indicated 30 | plans to implement? Are any existing implementations reported somewhere, 31 | either in the document itself (as [RFC 7942][3] recommends) or elsewhere 32 | (where)? 33 | 34 | ## Additional Reviews 35 | 36 | 5. Do the contents of this document closely interact with technologies in other 37 | IETF working groups or external organizations, and would it therefore benefit 38 | from their review? Have those reviews occurred? If yes, describe which 39 | reviews took place. 40 | 41 | 6. Describe how the document meets any required formal expert review criteria, 42 | such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 43 | 44 | 7. If the document contains a YANG module, has the final version of the module 45 | been checked with any of the [recommended validation tools][4] for syntax and 46 | formatting validation? If there are any resulting errors or warnings, what is 47 | the justification for not fixing them at this time? Does the YANG module 48 | comply with the Network Management Datastore Architecture (NMDA) as specified 49 | in [RFC 8342][5]? 50 | 51 | 8. Describe reviews and automated checks performed to validate sections of the 52 | final version of the document written in a formal language, such as XML code, 53 | BNF rules, MIB definitions, CBOR's CDDL, etc. 54 | 55 | ## Document Shepherd Checks 56 | 57 | 9. Based on the shepherd's review of the document, is it their opinion that this 58 | document is needed, clearly written, complete, correctly designed, and ready 59 | to be handed off to the responsible Area Director? 60 | 61 | 10. Several IETF Areas have assembled [lists of common issues that their 62 | reviewers encounter][6]. For which areas have such issues been identified 63 | and addressed? For which does this still need to happen in subsequent 64 | reviews? 65 | 66 | 11. What type of RFC publication is being requested on the IETF stream ([Best 67 | Current Practice][12], [Proposed Standard, Internet Standard][13], 68 | [Informational, Experimental or Historic][14])? Why is this the proper type 69 | of RFC? Do all Datatracker state attributes correctly reflect this intent? 70 | 71 | 12. Have reasonable efforts been made to remind all authors of the intellectual 72 | property rights (IPR) disclosure obligations described in [BCP 79][7]? To 73 | the best of your knowledge, have all required disclosures been filed? If 74 | not, explain why. If yes, summarize any relevant discussion, including links 75 | to publicly-available messages when applicable. 76 | 77 | 13. Has each author, editor, and contributor shown their willingness to be 78 | listed as such? If the total number of authors and editors on the front page 79 | is greater than five, please provide a justification. 80 | 81 | 14. Document any remaining I-D nits in this document. Simply running the [idnits 82 | tool][8] is not enough; please review the ["Content Guidelines" on 83 | authors.ietf.org][15]. (Also note that the current idnits tool generates 84 | some incorrect warnings; a rewrite is underway.) 85 | 86 | 15. Should any informative references be normative or vice-versa? See the [IESG 87 | Statement on Normative and Informative References][16]. 88 | 89 | 16. List any normative references that are not freely available to anyone. Did 90 | the community have sufficient access to review any such normative 91 | references? 92 | 93 | 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 94 | 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, 95 | list them. 96 | 97 | 18. Are there normative references to documents that are not ready to be 98 | submitted to the IESG for publication or are otherwise in an unclear state? 99 | If so, what is the plan for their completion? 100 | 101 | 19. Will publication of this document change the status of any existing RFCs? If 102 | so, does the Datatracker metadata correctly reflect this and are those RFCs 103 | listed on the title page, in the abstract, and discussed in the 104 | introduction? If not, explain why and point to the part of the document 105 | where the relationship of this document to these other RFCs is discussed. 106 | 107 | 20. Describe the document shepherd's review of the IANA considerations section, 108 | especially with regard to its consistency with the body of the document. 109 | Confirm that all aspects of the document requiring IANA assignments are 110 | associated with the appropriate reservations in IANA registries. Confirm 111 | that any referenced IANA registries have been clearly identified. Confirm 112 | that each newly created IANA registry specifies its initial contents, 113 | allocations procedures, and a reasonable name (see [RFC 8126][11]). 114 | 115 | 21. List any new IANA registries that require Designated Expert Review for 116 | future allocations. Are the instructions to the Designated Expert clear? 117 | Please include suggestions of designated experts, if appropriate. 118 | 119 | [1]: https://www.ietf.org/about/groups/iesg/ 120 | [2]: https://www.rfc-editor.org/rfc/rfc4858.html 121 | [3]: https://www.rfc-editor.org/rfc/rfc7942.html 122 | [4]: https://wiki.ietf.org/group/ops/yang-review-tools 123 | [5]: https://www.rfc-editor.org/rfc/rfc8342.html 124 | [6]: https://wiki.ietf.org/group/iesg/ExpertTopics 125 | [7]: https://www.rfc-editor.org/info/bcp79 126 | [8]: https://www.ietf.org/tools/idnits/ 127 | [9]: https://www.rfc-editor.org/rfc/rfc3967.html 128 | [10]: https://www.rfc-editor.org/info/bcp97 129 | [11]: https://www.rfc-editor.org/rfc/rfc8126.html 130 | [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 131 | [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 132 | [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 133 | [15]: https://authors.ietf.org/en/content-guidelines-overview 134 | [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ 135 | [17]: https://datatracker.ietf.org/doc/downref/ 136 | 137 | -------------------------------------------------------------------------------- /writeups/digest.md: -------------------------------------------------------------------------------- 1 | # Document Shepherd Writeup for draft-ietf-httpbis-digest-headers 2 | 3 | ## Document History 4 | 5 | 1. Does the working group (WG) consensus represent the strong concurrence of a 6 | few individuals, with others being silent, or did it reach broad agreement? 7 | 8 | _This document enjoyed broad discussion and two Working Group Last Calls._ 9 | 10 | 2. Was there controversy about particular points, or were there decisions where 11 | the consensus was particularly rough? 12 | 13 | _There were some philosophical differences about how backwards-compatible we should be, but 14 | we came to consensus._ 15 | 16 | 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If 17 | so, please summarize the areas of conflict in separate email messages to the 18 | responsible Area Director. (It should be in a separate email because this 19 | questionnaire is publicly available.) 20 | 21 | _Not to my knowledge._ 22 | 23 | 4. For protocol documents, are there existing implementations of the contents of 24 | the document? Have a significant number of potential implementers indicated 25 | plans to implement? Are any existing implementations reported somewhere, 26 | either in the document itself (as [RFC 7942][3] recommends) or elsewhere 27 | (where)? 28 | 29 | _There are some early implementations underway, and more have expressed interest._ 30 | 31 | ### Additional Reviews 32 | 33 | 5. Does this document need review from other IETF working groups or external 34 | organizations? Have those reviews occurred? 35 | 36 | _It's had involvement from security folks, but might benefit from the SecDir review as well._ 37 | 38 | 6. Describe how the document meets any required formal expert review criteria, 39 | such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 40 | 41 | _N/A_ 42 | 43 | 7. If the document contains a YANG module, has the final version of the module 44 | been checked with any of the [recommended validation tools][4] for syntax and 45 | formatting validation? If there are any resulting errors or warnings, what is 46 | the justification for not fixing them at this time? Does the YANG module 47 | comply with the Network Management Datastore Architecture (NMDA) as specified 48 | in [RFC 8342][5]? 49 | 50 | _N/A_ 51 | 52 | 8. Describe reviews and automated checks performed to validate sections of the 53 | final version of the document written in a formal language, such as XML code, 54 | BNF rules, MIB definitions, CBOR's CDDL, etc. 55 | 56 | _HTTP examples have been validated._ 57 | 58 | 59 | ### Document Shepherd Checks 60 | 61 | 9. Based on the shepherd's review of the document, is it their opinion that this 62 | document is needed, clearly written, complete, correctly designed, and ready 63 | to be handed off to the responsible Area Director? 64 | 65 | _Yes_ 66 | 67 | 10. Several IETF Areas have assembled [lists of common issues that their 68 | reviewers encounter][6]. Do any such issues remain that would merit specific 69 | attention from subsequent reviews? 70 | 71 | _The Working Group believes that the relevant listed issues have been addressed._ 72 | 73 | 11. What type of RFC publication is being requested on the IETF stream (Best 74 | Current Practice, Proposed Standard, Internet Standard, Informational, 75 | Experimental, or Historic)? Why is this the proper type of RFC? Do all 76 | Datatracker state attributes correctly reflect this intent? 77 | 78 | _Proposed Standard; because we believe there is consensus to publish it._ 79 | 80 | 12. Has the interested community confirmed that any and all appropriate IPR 81 | disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, 82 | explain why. If yes, summarize any discussion and conclusion regarding the 83 | intellectual property rights (IPR) disclosures, including links to relevant 84 | emails. 85 | 86 | _Yes; no relevant IPR has been disclosed._ 87 | 88 | 13. Has each Author or Contributor confirmed their willingness to be listed as 89 | such? If the number of Authors/Editors on the front page is greater than 5, 90 | please provide a justification. 91 | 92 | _Implicitly, yes._ 93 | 94 | 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] 95 | and the checkbox items found in Guidelines to Authors of Internet-Drafts). 96 | Simply running the idnits tool is not enough; please review the entire 97 | guidelines document. 98 | 99 | - There is a non-ASCII character in the reference for RFC9260. This should be resolved by the RFC Editor. 100 | 101 | 15. Should any informative references be normative or vice-versa? 102 | 103 | _No._ 104 | 105 | 16. List any normative references that are not freely available to anyone. Did 106 | the community have sufficient access to review any such normative 107 | references? 108 | 109 | _N/A._ 110 | 111 | 17. Are there any normative downward references (see [RFC 3967][10], 112 | [BCP 97][11])? If so, list them. 113 | 114 | _RFCs 1321; 1950; 3174; 6234._ 115 | 116 | 18. Are there normative references to documents that are not ready for 117 | advancement or are otherwise in an unclear state? If they exist, what is the 118 | plan for their completion? 119 | 120 | _No._ 121 | 122 | 19. Will publication of this document change the status of any existing RFCs? If 123 | so, does the Datatracker metadata correctly reflect this and are those RFCs 124 | listed on the title page, in the abstract, and discussed in the 125 | introduction? If not, explain why and point to the part of the document 126 | where the relationship of this document to these other RFCs is discussed. 127 | 128 | _Yes; There is no apparent way to reflect this in datatracker; Yes._ 129 | 130 | 20. Describe the document shepherd's review of the IANA considerations section, 131 | especially with regard to its consistency with the body of the document. 132 | Confirm that all aspects of the document requiring IANA assignments are 133 | associated with the appropriate reservations in IANA registries. Confirm 134 | that any referenced IANA registries have been clearly identified. Confirm 135 | that each newly created IANA registry specifies its initial contents, 136 | allocations procedures, and a reasonable name (see [RFC 8126][12]). 137 | 138 | _I checked section 7 of the draft against its references; all looks to be in order._ 139 | 140 | 21. List any new IANA registries that require Designated Expert Review for 141 | future allocations. Are the instructions to the Designated Expert clear? 142 | Please include suggestions of designated experts, if appropriate. 143 | 144 | - Hash Algorithms for HTTP Digest Fields Registry. The instructions are brief but clear. I'd suggest one or both of the authors. 145 | 146 | 147 | [1]: https://www.ietf.org/about/groups/iesg/ 148 | [2]: https://www.rfc-editor.org/rfc/rfc4858.html 149 | [3]: https://www.rfc-editor.org/rfc/rfc7942.html 150 | [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools 151 | [5]: https://www.rfc-editor.org/rfc/rfc8342.html 152 | [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics 153 | [7]: https://www.rfc-editor.org/info/bcp78 154 | [8]: https://www.rfc-editor.org/info/bcp79 155 | [9]: https://www.ietf.org/tools/idnits/ 156 | [10]: https://www.rfc-editor.org/rfc/rfc3967.html 157 | [11]: https://www.rfc-editor.org/info/bcp97 158 | [12]: https://www.rfc-editor.org/rfc/rfc8126.html 159 | 160 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-immutable.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: HTTP Immutable Responses 3 | docname: draft-ietf-httpbis-immutable-03 4 | date: 2017 5 | category: std 6 | ipr: trust200902 7 | area: Applications and Real-Time 8 | workgroup: HTTP 9 | 10 | pi: 11 | toc: yes 12 | 13 | author: 14 | - 15 | ins: P. McManus 16 | name: Patrick McManus 17 | organization: Mozilla 18 | email: mcmanus@ducksong.com 19 | 20 | normative: 21 | RFC2119: 22 | RFC7232: 23 | RFC7234: 24 | RFC8174: 25 | 26 | informative: 27 | REQPERPAGE: 28 | author: 29 | - 30 | organization: HTTP Archive 31 | target: http://httparchive.org/interesting.php#reqTotal 32 | title: "Total Requests per Page" 33 | date: false 34 | 35 | --- abstract 36 | 37 | The immutable HTTP response Cache-Control extension allows servers to identify 38 | resources that will not be updated during their freshness lifetime. This 39 | ensures that a client never needs to revalidate a cached fresh resource to be 40 | certain it has not been modified. 41 | 42 | --- note_Note_to_Readers 43 | 44 | Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), 45 | which is archived at . 46 | 47 | Working Group information can be found at ; source 48 | code and issues list for this draft can be found at 49 | . 50 | 51 | --- middle 52 | 53 | # Introduction 54 | 55 | HTTP's freshness lifetime mechanism [RFC7234] allows a client to safely reuse a 56 | stored response to satisfy future requests for a specified period of time. 57 | However, it is still possible that the resource will be modified during that 58 | period. 59 | 60 | For instance, a front-page newspaper photo with a freshness lifetime of one 61 | hour would mean that no user would see a cached photo more than one hour old. 62 | However, the photo could be updated at any time, resulting in different users 63 | seeing different photos depending on the contents of their caches for up to one 64 | hour. This is compliant with the caching mechanism defined in [RFC7234]. 65 | 66 | Users that need to confirm there have been no updates to their cached responses 67 | typically use the reload (or refresh) mechanism in their user agents. This in 68 | turn generates a conditional request [RFC7232], and either a new representation 69 | or, if unmodified, a 304 (Not Modified) response [RFC7232] is returned. A user 70 | agent that understands HTML and fetches its dependent sub-resources might issue 71 | hundreds of conditional requests to refresh all portions of a common page 72 | [REQPERPAGE]. 73 | 74 | However, some content providers never create more than one variant of a 75 | sub-resource, because they use "versioned" URLs. When these resources need an 76 | update, they are simply published under a new URL, typically embedding an 77 | identifier unique to that version of the resource in the path, and references 78 | to the sub-resource are updated with the new path information. 79 | 80 | For example, `https://www.example.com/101016/main.css` might be updated and 81 | republished as `https://www.example.com/102026/main.css`, with any links that 82 | reference it being changed at the same time. This design pattern allows a very 83 | large freshness lifetime to be used for the sub-resource without guessing 84 | when it will be updated in the future. 85 | 86 | Unfortunately, the user agent does not know when this versioned URL design 87 | pattern is used. As a result, user-driven refreshes still translate into wasted 88 | conditional requests for each sub-resource as each will return 304 responses. 89 | 90 | The immutable HTTP response Cache-Control extension allows servers to 91 | identify responses that will not be updated during their freshness lifetimes. 92 | 93 | This effectively informs clients that any conditional request for that response 94 | can be safely skipped without worrying that it has been updated. 95 | 96 | ## Notational Conventions 97 | 98 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 | "OPTIONAL" in this document are to be interpreted as described in BCP 101 | 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all 102 | capitals, as shown here. 103 | 104 | # The Immutable Cache-Control Extension 105 | 106 | When present in an HTTP response, the immutable Cache-Control 107 | extension indicates that the origin server will not update the representation 108 | of that resource during the freshness lifetime of the 109 | response. 110 | 111 | Clients SHOULD NOT issue a conditional request during the 112 | response's freshness lifetime (e.g., upon a reload) unless explicitly 113 | overridden by the user (e.g., a force reload). 114 | 115 | The immutable extension only applies during the freshness lifetime of the 116 | stored response. Stale responses SHOULD be revalidated as they normally would 117 | be in the absence of the immutable extension. 118 | 119 | The immutable extension takes no arguments. If any arguments are present, they 120 | have no meaning and MUST be ignored. Multiple instances of the immutable 121 | extension are equivalent to one instance. The presence of an immutable 122 | Cache-Control extension in a request has no effect. 123 | 124 | ## About Intermediaries 125 | 126 | An immutable response has the same semantic meaning when received by 127 | proxy clients as it does when received by user-agent-based 128 | clients. Therefore, proxies SHOULD skip conditionally revalidating fresh 129 | responses containing the immutable extension unless there is a signal 130 | from the client that a validation is necessary (e.g., a no-cache 131 | Cache-Control request directive defined in Section 5.2.1.4 of [RFC7234]). 132 | 133 | A proxy that uses the immutable extension to bypass a conditional revalidation can choose 134 | whether to reply with a 304 or 200 response to its requesting client based on 135 | the request headers the proxy received. 136 | 137 | ## Example 138 | 139 | ~~~ example 140 | Cache-Control: max-age=31536000, immutable 141 | ~~~ 142 | 143 | # Security Considerations 144 | 145 | The immutable mechanism acts as form of soft pinning and, as with all pinning 146 | mechanisms, creates a vector for amplification of cache corruption incidents. 147 | These incidents include cache-poisoning attacks. Three mechanisms are suggested 148 | for mitigation of this risk: 149 | 150 | * Clients SHOULD ignore the immutable extension from resources that are not part of an 151 | authenticated context such as HTTPS. Authenticated resources are less 152 | vulnerable to cache poisoning. 153 | 154 | * User agents often provide two different refresh mechanisms: reload and some 155 | form of force-reload. The latter is used to rectify interrupted loads and 156 | other corruption. These reloads, typically indicated through no-cache request 157 | attributes, SHOULD ignore the immutable extension as well. 158 | 159 | * Clients SHOULD ignore the immutable extension for resources that do not provide a strong 160 | indication that the stored response size is the correct response size such as 161 | responses delimited by connection close. 162 | 163 | # IANA Considerations 164 | 165 | The immutable extension has been registered in the "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" 166 | per the guidelines described in Section 7.1 of {{RFC7234}}. 167 | 168 | * Cache Directive: immutable 169 | * Reference: RFC 8246 170 | 171 | --- back 172 | 173 | # Acknowledgments 174 | {:numbered="false"} 175 | Thank you to Ben Maurer for partnership in developing and testing this 176 | idea. Thank you to Amos Jeffries for help with proxy interactions and 177 | to Mark Nottingham for help with the documentation. 178 | -------------------------------------------------------------------------------- /writeups/zstd-window-size.md: -------------------------------------------------------------------------------- 1 | # Document Shepherd Write-Up for Group Documents 2 | 3 | *This version is dated 4 July 2022.* 4 | 5 | Thank you for your service as a document shepherd. Among the responsibilities is 6 | answering the questions in this write-up to give helpful context to Last Call 7 | and Internet Engineering Steering Group ([IESG][1]) reviewers, and your 8 | diligence in completing it is appreciated. The full role of the shepherd is 9 | further described in [RFC 4858][2]. You will need the cooperation of the authors 10 | and editors to complete these checks. 11 | 12 | Note that some numbered items contain multiple related questions; please be sure 13 | to answer all of them. 14 | 15 | ## Document History 16 | 17 | 1. Does the working group (WG) consensus represent the strong concurrence of a 18 | few individuals, with others being silent, or did it reach broad agreement? 19 | 20 | Broad agreement. 21 | 22 | 2. Was there controversy about particular points, or were there decisions where 23 | the consensus was particularly rough? 24 | 25 | No; this was remarkably easy. 26 | 27 | 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If 28 | so, please summarize the areas of conflict in separate email messages to the 29 | responsible Area Director. (It should be in a separate email because this 30 | questionnaire is publicly available.) 31 | 32 | No. 33 | 34 | 4. For protocol documents, are there existing implementations of the contents of 35 | the document? Have a significant number of potential implementers indicated 36 | plans to implement? Are any existing implementations reported somewhere, 37 | either in the document itself (as [RFC 7942][3] recommends) or elsewhere 38 | (where)? 39 | 40 | Implementers have expressed an intent to align on the draft's recommendations. 41 | 42 | ## Additional Reviews 43 | 44 | 5. Do the contents of this document closely interact with technologies in other 45 | IETF working groups or external organizations, and would it therefore benefit 46 | from their review? Have those reviews occurred? If yes, describe which 47 | reviews took place. 48 | 49 | N/A 50 | 51 | 6. Describe how the document meets any required formal expert review criteria, 52 | such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 53 | 54 | N/A 55 | 56 | 7. If the document contains a YANG module, has the final version of the module 57 | been checked with any of the [recommended validation tools][4] for syntax and 58 | formatting validation? If there are any resulting errors or warnings, what is 59 | the justification for not fixing them at this time? Does the YANG module 60 | comply with the Network Management Datastore Architecture (NMDA) as specified 61 | in [RFC 8342][5]? 62 | 63 | N/A 64 | 65 | 8. Describe reviews and automated checks performed to validate sections of the 66 | final version of the document written in a formal language, such as XML code, 67 | BNF rules, MIB definitions, CBOR's CDDL, etc. 68 | 69 | N/A 70 | 71 | ## Document Shepherd Checks 72 | 73 | 9. Based on the shepherd's review of the document, is it their opinion that this 74 | document is needed, clearly written, complete, correctly designed, and ready 75 | to be handed off to the responsible Area Director? 76 | 77 | Yes. 78 | 79 | 10. Several IETF Areas have assembled [lists of common issues that their 80 | reviewers encounter][6]. For which areas have such issues been identified 81 | and addressed? For which does this still need to happen in subsequent 82 | reviews? 83 | 84 | N/A 85 | 86 | 11. What type of RFC publication is being requested on the IETF stream ([Best 87 | Current Practice][12], [Proposed Standard, Internet Standard][13], 88 | [Informational, Experimental or Historic][14])? Why is this the proper type 89 | of RFC? Do all Datatracker state attributes correctly reflect this intent? 90 | 91 | Informational; it is an update to another Informational RFC. 92 | 93 | 12. Have reasonable efforts been made to remind all authors of the intellectual 94 | property rights (IPR) disclosure obligations described in [BCP 79][7]? To 95 | the best of your knowledge, have all required disclosures been filed? If 96 | not, explain why. If yes, summarize any relevant discussion, including links 97 | to publicly-available messages when applicable. 98 | 99 | Yes. 100 | 101 | 13. Has each author, editor, and contributor shown their willingness to be 102 | listed as such? If the total number of authors and editors on the front page 103 | is greater than five, please provide a justification. 104 | 105 | Yes. 106 | 107 | 14. Document any remaining I-D nits in this document. Simply running the [idnits 108 | tool][8] is not enough; please review the ["Content Guidelines" on 109 | authors.ietf.org][15]. (Also note that the current idnits tool generates 110 | some incorrect warnings; a rewrite is underway.) 111 | 112 | All good. 113 | 114 | 15. Should any informative references be normative or vice-versa? See the [IESG 115 | Statement on Normative and Informative References][16]. 116 | 117 | No. 118 | 119 | 16. List any normative references that are not freely available to anyone. Did 120 | the community have sufficient access to review any such normative 121 | references? 122 | 123 | N/A. 124 | 125 | 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 126 | 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, 127 | list them. 128 | 129 | No. 130 | 131 | 18. Are there normative references to documents that are not ready to be 132 | submitted to the IESG for publication or are otherwise in an unclear state? 133 | If so, what is the plan for their completion? 134 | 135 | No. 136 | 137 | 19. Will publication of this document change the status of any existing RFCs? If 138 | so, does the Datatracker metadata correctly reflect this and are those RFCs 139 | listed on the title page, in the abstract, and discussed in the 140 | introduction? If not, explain why and point to the part of the document 141 | where the relationship of this document to these other RFCs is discussed. 142 | 143 | No. 144 | 145 | 20. Describe the document shepherd's review of the IANA considerations section, 146 | especially with regard to its consistency with the body of the document. 147 | Confirm that all aspects of the document requiring IANA assignments are 148 | associated with the appropriate reservations in IANA registries. Confirm 149 | that any referenced IANA registries have been clearly identified. Confirm 150 | that each newly created IANA registry specifies its initial contents, 151 | allocations procedures, and a reasonable name (see [RFC 8126][11]). 152 | 153 | Just a simple update. 154 | 155 | 21. List any new IANA registries that require Designated Expert Review for 156 | future allocations. Are the instructions to the Designated Expert clear? 157 | Please include suggestions of designated experts, if appropriate. 158 | 159 | N/A. 160 | 161 | [1]: https://www.ietf.org/about/groups/iesg/ 162 | [2]: https://www.rfc-editor.org/rfc/rfc4858.html 163 | [3]: https://www.rfc-editor.org/rfc/rfc7942.html 164 | [4]: https://wiki.ietf.org/group/ops/yang-review-tools 165 | [5]: https://www.rfc-editor.org/rfc/rfc8342.html 166 | [6]: https://wiki.ietf.org/group/iesg/ExpertTopics 167 | [7]: https://www.rfc-editor.org/info/bcp79 168 | [8]: https://www.ietf.org/tools/idnits/ 169 | [9]: https://www.rfc-editor.org/rfc/rfc3967.html 170 | [10]: https://www.rfc-editor.org/info/bcp97 171 | [11]: https://www.rfc-editor.org/rfc/rfc8126.html 172 | [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 173 | [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 174 | [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 175 | [15]: https://authors.ietf.org/en/content-guidelines-overview 176 | [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ 177 | [17]: https://datatracker.ietf.org/doc/downref/ 178 | 179 | -------------------------------------------------------------------------------- /draft-ietf-httpbis-cache-groups.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: HTTP Cache Groups 3 | abbrev: 4 | docname: draft-ietf-httpbis-cache-groups-latest 5 | date: {DATE} 6 | category: std 7 | 8 | ipr: trust200902 9 | keyword: HTTP, Caching, Invalidation 10 | workgroup: HTTP 11 | area: Web and Internet Transport 12 | 13 | stand_alone: yes 14 | smart_quotes: no 15 | pi: [toc, tocindent, sortrefs, symrefs, strict, compact, comments, inline] 16 | 17 | venue: 18 | group: HTTP 19 | type: Working Group 20 | home: https://httpwg.org/ 21 | mail: ietf-http-wg@w3.org 22 | arch: https://lists.w3.org/Archives/Public/ietf-http-wg/ 23 | repo: https://github.com/httpwg/http-extensions/labels/cache-groups 24 | github-issue-label: cache-groups 25 | 26 | author: 27 | - 28 | ins: M. Nottingham 29 | name: Mark Nottingham 30 | organization: Cloudflare 31 | postal: 32 | - Melbourne 33 | country: Australia 34 | email: mnot@mnot.net 35 | uri: https://www.mnot.net/ 36 | 37 | normative: 38 | HTTP: RFC9110 39 | HTTP-CACHING: RFC9111 40 | STRUCTURED-FIELDS: RFC9651 41 | 42 | informative: 43 | TARGETED: RFC9213 44 | 45 | entity: 46 | SELF: "RFC nnnn" 47 | 48 | --- abstract 49 | 50 | This specification introduces a means of describing the relationships between stored responses in HTTP caches, grouping them by associating a stored response with one or more strings. 51 | 52 | --- middle 53 | 54 | 55 | # Introduction 56 | 57 | HTTP caching {{HTTP-CACHING}} operates at the granularity of a single resource; the freshness of one stored response does not affect that of others. This granularity can make caching more efficient -- for example, when a page is composed of many assets that have different requirements for caching. 58 | 59 | However, there are also cases where the relationship between stored responses could be used to improve cache efficiency. 60 | 61 | For example, it is often necessary to invalidate a set of related resources. This might be because a state-changing request has side effects on other resources, or it might be purely for administrative convenience (e.g., "invalidate this part of the site"). Grouping responses together provides a dedicated way to express these relationships, instead of relying on things like URL structure. 62 | 63 | In addition to sharing invalidation events, the relationships indicated by grouping can also be used by caches to optimise their operation (e.g., to inform the operation of cache eviction algorithms). 64 | 65 | {{cache-groups}} introduces a means of describing the relationships between stored responses in HTTP caches, by associating those responses with one or more groups that reflect those relationships. It also describes how caches can use that information to apply invalidation events to members of a group. 66 | 67 | {{cache-group-invalidation}} introduces one new source of such events: a HTTP response header field that allows a state-changing response to trigger a group invalidation. 68 | 69 | These mechanisms operate within a single cache, across the stored responses associated with a single origin server (see {{identify}}). They do not address the issues of synchronising state between multiple caches (e.g., in a hierarchy or mesh), nor do they facilitate association of stored responses from disparate origins. 70 | 71 | 72 | ## Notational Conventions 73 | 74 | {::boilerplate bcp14-tagged} 75 | 76 | This specification uses the following terminology from {{STRUCTURED-FIELDS}}: List, String, Parameter. 77 | 78 | 79 | # The Cache-Groups Response Header Field {#cache-groups} 80 | 81 | The Cache-Groups HTTP response header field is a List of Strings ({{Sections 3.1 and 3.3.3 of STRUCTURED-FIELDS}}). Each member of the List is a value that identifies a group that the response belongs to. These Strings are opaque -- while they might have some meaning to the server that creates them, the cache does not have any insight into their structure or content (beyond uniquely identifying a group). 82 | 83 | ~~~ http-message 84 | HTTP/1.1 200 OK 85 | Content-Type: application/javascript 86 | Cache-Control: max-age=3600 87 | Cache-Groups: "scripts" 88 | ~~~ 89 | 90 | The ordering of members is not significant. Unrecognised Parameters are to be ignored. 91 | 92 | Implementations MUST support at least 32 groups in a field value, with up to at least 32 characters in each member. Note that generic limitations on HTTP field lengths may constrain the size of this field value in practice. 93 | 94 | ## Identifying Grouped Responses {#identify} 95 | 96 | Two responses stored in the same cache are considered to belong to the same group when all of the following conditions are met: 97 | 98 | 1. They both contain a Cache-Groups response header field that contains the same String (in any position in the List), when compared character-by-character (case sensitive). 99 | 2. They both share the same URI origin (per {{Section 4.3.1 of HTTP}}). 100 | 101 | 102 | ## Cache Behaviour 103 | 104 | ### Invalidation {#invalidation} 105 | 106 | A cache that invalidates a stored response MAY invalidate any stored responses that share groups (per {{identify}}) with that response. Note that further grouped invalidations are not triggered by a grouped invalidation; i.e., this mechanism does not cascade. 107 | 108 | Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field {{TARGETED}} might specify that caches processing it are required to invalidate such responses. 109 | 110 | 111 | # The Cache-Group-Invalidation Response Header Field {#cache-group-invalidation} 112 | 113 | The Cache-Group-Invalidation response header field is a List of Strings ({{Sections 3.1 and 3.3.3 of STRUCTURED-FIELDS}}). Each member of the List is a value that identifies a group that the response invalidates, per {{invalidation}}. 114 | 115 | For example, following a POST request that has side effects on two cache groups, the corresponding response could indicate that stored responses associated with either or both of those groups should be invalidated with: 116 | 117 | ~~~ http-message 118 | HTTP/1.1 200 OK 119 | Content-Type: text/html 120 | Cache-Group-Invalidation: "eurovision-results", "australia" 121 | ~~~ 122 | 123 | The Cache-Group-Invalidation header field MUST be ignored on responses to requests that have a safe method (e.g., GET; see {{Section 9.2.1 of HTTP}}). 124 | 125 | A cache that receives a Cache-Group-Invalidation header field on a response to an unsafe request MAY invalidate any stored responses that share groups (per {{identify}}) with any of the listed groups. 126 | 127 | Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field {{TARGETED}} might specify that caches processing it are required to respect the Cache-Group-Invalidation signal. 128 | 129 | The ordering of members is not significant. Unrecognised Parameters are to be ignored. 130 | 131 | Implementations MUST support at least 32 groups in a field value, with up to at least 32 characters in each member. Note that generic limitations on HTTP field lengths may constrain the size of this field value in practice. 132 | 133 | # IANA Considerations 134 | 135 | IANA should perform the following tasks: 136 | 137 | ## HTTP Field Names 138 | 139 | Enter the following into the Hypertext Transfer Protocol (HTTP) Field Name Registry: 140 | 141 | - Field Name: Cache-Groups 142 | - Status: permanent 143 | - Reference: {{&SELF}} 144 | - Comments: 145 | 146 | - Field Name: Cache-Group-Invalidation 147 | - Status: permanent 148 | - Reference: {{&SELF}} 149 | - Comments: 150 | 151 | 152 | # Security Considerations 153 | 154 | This mechanism allows resources that share an origin to invalidate each other. Because of this, 155 | origins that represent multiple parties (sometimes referred to as "shared hosting") might allow 156 | one party to group its resources with those of others, or to send signals which have side effects upon them. 157 | 158 | Shared hosts that wish to mitigate these risks can control access to the header fields defined in this specification. 159 | 160 | 161 | --- back 162 | 163 | # Acknowledgements 164 | 165 | Thanks to Stephen Ludin for his review and suggestions. 166 | 167 | -------------------------------------------------------------------------------- /writeups/alias-proxy-status.md: -------------------------------------------------------------------------------- 1 | # Document Shepherd Write-Up for Group Documents 2 | 3 | *This version is dated 4 July 2022.* 4 | 5 | Thank you for your service as a document shepherd. Among the responsibilities is 6 | answering the questions in this write-up to give helpful context to Last Call 7 | and Internet Engineering Steering Group ([IESG][1]) reviewers, and your 8 | diligence in completing it is appreciated. The full role of the shepherd is 9 | further described in [RFC 4858][2]. You will need the cooperation of the authors 10 | and editors to complete these checks. 11 | 12 | Note that some numbered items contain multiple related questions; please be sure 13 | to answer all of them. 14 | 15 | ## Document History 16 | 17 | 1. Does the working group (WG) consensus represent the strong concurrence of a 18 | few individuals, with others being silent, or did it reach broad agreement? 19 | 20 | There was a reasonable breadth of discussion regarding this document. 21 | 22 | 2. Was there controversy about particular points, or were there decisions where 23 | the consensus was particularly rough? 24 | 25 | Nothing was controversial. 26 | 27 | 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If 28 | so, please summarize the areas of conflict in separate email messages to the 29 | responsible Area Director. (It should be in a separate email because this 30 | questionnaire is publicly available.) 31 | 32 | Not to my knowledge. 33 | 34 | 4. For protocol documents, are there existing implementations of the contents of 35 | the document? Have a significant number of potential implementers indicated 36 | plans to implement? Are any existing implementations reported somewhere, 37 | either in the document itself (as [RFC 7942][3] recommends) or elsewhere 38 | (where)? 39 | 40 | Yes; Apple and its partners have implemented and deployed. 41 | 42 | ## Additional Reviews 43 | 44 | 5. Do the contents of this document closely interact with technologies in other 45 | IETF working groups or external organizations, and would it therefore benefit 46 | from their review? Have those reviews occurred? If yes, describe which 47 | reviews took place. 48 | 49 | N/A 50 | 51 | 6. Describe how the document meets any required formal expert review criteria, 52 | such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 53 | 54 | N/A 55 | 56 | 7. If the document contains a YANG module, has the final version of the module 57 | been checked with any of the [recommended validation tools][4] for syntax and 58 | formatting validation? If there are any resulting errors or warnings, what is 59 | the justification for not fixing them at this time? Does the YANG module 60 | comply with the Network Management Datastore Architecture (NMDA) as specified 61 | in [RFC 8342][5]? 62 | 63 | N/A 64 | 65 | 8. Describe reviews and automated checks performed to validate sections of the 66 | final version of the document written in a formal language, such as XML code, 67 | BNF rules, MIB definitions, CBOR's CDDL, etc. 68 | 69 | N/A 70 | 71 | ## Document Shepherd Checks 72 | 73 | 9. Based on the shepherd's review of the document, is it their opinion that this 74 | document is needed, clearly written, complete, correctly designed, and ready 75 | to be handed off to the responsible Area Director? 76 | 77 | Yes. 78 | 79 | 10. Several IETF Areas have assembled [lists of common issues that their 80 | reviewers encounter][6]. For which areas have such issues been identified 81 | and addressed? For which does this still need to happen in subsequent 82 | reviews? 83 | 84 | We've looked at it and seen no obviously large issues. Use of IP addresses and TLS ALPN tokens might merit further review. 85 | 86 | 11. What type of RFC publication is being requested on the IETF stream ([Best 87 | Current Practice][12], [Proposed Standard, Internet Standard][13], 88 | [Informational, Experimental or Historic][14])? Why is this the proper type 89 | of RFC? Do all Datatracker state attributes correctly reflect this intent? 90 | 91 | Proposes Standard. 92 | 93 | 12. Have reasonable efforts been made to remind all authors of the intellectual 94 | property rights (IPR) disclosure obligations described in [BCP 79][7]? To 95 | the best of your knowledge, have all required disclosures been filed? If 96 | not, explain why. If yes, summarize any relevant discussion, including links 97 | to publicly-available messages when applicable. 98 | 99 | Private discussion. 100 | 101 | 13. Has each author, editor, and contributor shown their willingness to be 102 | listed as such? If the total number of authors and editors on the front page 103 | is greater than five, please provide a justification. 104 | 105 | Implicitly. 106 | 107 | 14. Document any remaining I-D nits in this document. Simply running the [idnits 108 | tool][8] is not enough; please review the ["Content Guidelines" on 109 | authors.ietf.org][15]. (Also note that the current idnits tool generates 110 | some incorrect warnings; a rewrite is underway.) 111 | 112 | Nits were found and addressed. 113 | 114 | 15. Should any informative references be normative or vice-versa? See the [IESG 115 | Statement on Normative and Informative References][16]. 116 | 117 | No. 118 | 119 | 16. List any normative references that are not freely available to anyone. Did 120 | the community have sufficient access to review any such normative 121 | references? 122 | 123 | N/A 124 | 125 | 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 126 | 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, 127 | list them. 128 | 129 | No. 130 | 131 | 18. Are there normative references to documents that are not ready to be 132 | submitted to the IESG for publication or are otherwise in an unclear state? 133 | If so, what is the plan for their completion? 134 | 135 | No. 136 | 137 | 19. Will publication of this document change the status of any existing RFCs? If 138 | so, does the Datatracker metadata correctly reflect this and are those RFCs 139 | listed on the title page, in the abstract, and discussed in the 140 | introduction? If not, explain why and point to the part of the document 141 | where the relationship of this document to these other RFCs is discussed. 142 | 143 | No. 144 | 145 | 20. Describe the document shepherd's review of the IANA considerations section, 146 | especially with regard to its consistency with the body of the document. 147 | Confirm that all aspects of the document requiring IANA assignments are 148 | associated with the appropriate reservations in IANA registries. Confirm 149 | that any referenced IANA registries have been clearly identified. Confirm 150 | that each newly created IANA registry specifies its initial contents, 151 | allocations procedures, and a reasonable name (see [RFC 8126][11]). 152 | 153 | Seems legit. 154 | 155 | 21. List any new IANA registries that require Designated Expert Review for 156 | future allocations. Are the instructions to the Designated Expert clear? 157 | Please include suggestions of designated experts, if appropriate. 158 | 159 | N/A 160 | 161 | [1]: https://www.ietf.org/about/groups/iesg/ 162 | [2]: https://www.rfc-editor.org/rfc/rfc4858.html 163 | [3]: https://www.rfc-editor.org/rfc/rfc7942.html 164 | [4]: https://wiki.ietf.org/group/ops/yang-review-tools 165 | [5]: https://www.rfc-editor.org/rfc/rfc8342.html 166 | [6]: https://wiki.ietf.org/group/iesg/ExpertTopics 167 | [7]: https://www.rfc-editor.org/info/bcp79 168 | [8]: https://www.ietf.org/tools/idnits/ 169 | [9]: https://www.rfc-editor.org/rfc/rfc3967.html 170 | [10]: https://www.rfc-editor.org/info/bcp97 171 | [11]: https://www.rfc-editor.org/rfc/rfc8126.html 172 | [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 173 | [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 174 | [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 175 | [15]: https://authors.ietf.org/en/content-guidelines-overview 176 | [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ 177 | [17]: https://datatracker.ietf.org/doc/downref/ 178 | 179 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-header-structure.poc_parser.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | from __future__ import print_function 4 | 5 | ####################################################################### 6 | # Normally constructed as static table(s) at compile-time 7 | 8 | def buildset(l,d): 9 | s = set() 10 | for a,b in l: 11 | for j in range(a, b + 1): 12 | s.add("%c" % j) 13 | for c in d: 14 | s.add(c) 15 | return s 16 | 17 | 18 | rfc7230_tchar = buildset(((0x30,0x39), (0x41,0x5a), (0x61,0x7a),), 19 | "!#$%&'*+-.^_`|~") 20 | 21 | rfc7230_ows = buildset([], " \t") 22 | 23 | rfc4648_base64 = buildset(((0x30,0x39), (0x41,0x5a), (0x61,0x7a),), "+/") 24 | assert len(rfc4648_base64) == 64 25 | rfc4648_base64.add('=') 26 | 27 | h1_string = buildset(((0x20,0x21), (0x23,0x5b), (0x5d,0x7e),), "") 28 | bcp137_hexdig = buildset(( (0x30, 0x39), (0x41, 0x46),), "") 29 | 30 | ####################################################################### 31 | 32 | class Error(Exception): 33 | """I'm sorry Dave, I cannot do that.""" 34 | pass 35 | 36 | # We use a single element list as a "arg-by-reference" to the string we 37 | # are parsing. 38 | 39 | def assert_raw(raw): 40 | assert type(raw) == list and len(raw) == 1 and type(raw[0]) == str 41 | 42 | def skip_ows(raw, extra = 0): 43 | assert_raw(raw) 44 | s = raw[0][extra:] 45 | while len(s) > 0 and s[0] in rfc7230_ows: 46 | s = s[1:] 47 | raw[0] = s 48 | 49 | CS_IDENTIFIER = "IDENTIFIER" 50 | CS_NUMBER = "NUMBER" 51 | CS_INTEGER = "INTEGER" 52 | CS_ASCII_STRING = "ASCII_STRING" 53 | CS_UNICODE_STRING = "UNICODE_STRING" 54 | CS_BLOB = "BLOB" 55 | CS_TIMESTAMP = "TIMESTAMP" 56 | 57 | class CSval(object): 58 | def __init__(self, raw): 59 | self.canbe = set() 60 | self.raw = None 61 | 62 | assert_raw(raw) 63 | skip_ows(raw) 64 | s = raw[0] 65 | if len(s) == 0: 66 | raise Error("CSval expected, have empty string") 67 | 68 | # identifier|integer|number|timestamp 69 | if s[0] in rfc7230_tchar: 70 | self.raw, raw[0] = self.get_identifier(s) 71 | self.canbe.add(CS_IDENTIFIER) 72 | 73 | # XXX: should be done in first pass 74 | if self.raw[0].isdigit(): 75 | n = 0 76 | elif self.raw[0] == "-": 77 | n = 1 78 | else: 79 | return 80 | 81 | d = self.raw[n:].find(".") 82 | if d == 1: 83 | if self.raw[n:].isdigit() and len(self.raw)<=19: 84 | self.canbe.add(CS_INTEGER) 85 | return 86 | if d == 0 or d >= 14 or not self.raw[n:n+d].isdigit(): 87 | return 88 | if not self.raw[n+d+1:].isdigit(): 89 | return 90 | f = len(self.raw) - (n+d+1) 91 | if f < 1 or f+d > 15: 92 | return 93 | self.canbe.add(CS_NUMBER) 94 | self.canbe.add(CS_TIMESTAMP) 95 | return 96 | 97 | # h1-ascii-string|h1-unicode-string 98 | if s[0] == '"': 99 | u,self.raw,raw[0] = self.get_string(s) 100 | if u: 101 | self.canbe.add(CS_UNICODE_STRING) 102 | else: 103 | self.canbe.add(CS_ASCII_STRING) 104 | return 105 | 106 | # h1-blob-string|h1-unicode-string 107 | if s[0] == ':': 108 | self.raw,raw[0] = self.get_blob(s) 109 | self.canbe.add(CS_BLOB) 110 | return 111 | 112 | raise Error("Cannot parse value") 113 | 114 | def __repr__(self): 115 | return "<%s '%s'>" % (",".join(self.canbe), self.raw) 116 | 117 | def get_string(self, s): 118 | j = 1 119 | b = bytearray(s) 120 | uc = False 121 | while b[j] != 0x22: 122 | if b[j] != 0x5c: 123 | if s[j] not in h1_string: 124 | raise Error( 125 | "Illegal char (0x%02x)" % b[j]) 126 | j += 1 127 | elif b[j+1] in (0x5c, 0x22): 128 | j += 2 129 | elif b[j+1] != 0x75: 130 | raise Error("Illegal back-slash escape") 131 | elif b[j+2] != 0x27: 132 | raise Error("Illegal back-slash escape") 133 | else: 134 | uc = True 135 | j += 3 136 | while b[j] != 0x27: 137 | if s[j] not in bcp137_hexdig: 138 | raise Error("non-hex unicode") 139 | j += 1 140 | j += 1 141 | return uc,s[:j+1], s[j+2:] 142 | 143 | def get_blob(self, s): 144 | j = 1 145 | while s[j] != ':': 146 | if s[j] not in rfc4648_base64: 147 | raise Error("Bad base64") 148 | j += 1 149 | return s[:j+1], s[j+2:] 150 | 151 | def get_token(self, s): 152 | t = "" 153 | while len(s) > 0 and s[0] in rfc7230_tchar: 154 | t += s[0] 155 | s = s[1:] 156 | return t,s 157 | 158 | def get_identifier(self, s): 159 | t,s = self.get_token(s) 160 | if len(s) == 0 or s[0] != "/": 161 | return t,s 162 | tt, s = self.get_token(s[1:]) 163 | return t + "/" + tt, s 164 | 165 | 166 | class Cshdr(object): 167 | def __init__(self, input): 168 | self.input = input 169 | self.self_identified = False 170 | self.dicts = [] 171 | self.parse() 172 | 173 | def parse(self): 174 | raw = [self.input] 175 | self.field_name = CSval(raw) 176 | if raw[0][0] != ':': 177 | raise Error("No colon after field-name") 178 | skip_ows(raw, 1) 179 | if len(raw[0]) == 0: 180 | return 181 | if raw[0][0] == '>': 182 | if raw[0][-1] != "<": 183 | raise Error("Missing '<' at end") 184 | raw[0] = raw[0][:-1] 185 | self.self_identified = True 186 | skip_ows(raw, 1) 187 | while len(raw[0]) > 0: 188 | dn = CSval(raw) 189 | dc = {} 190 | self.dicts.append((dn, dc)) 191 | skip_ows(raw) 192 | 193 | while len(raw[0]) > 0 and raw[0][0] == ";": 194 | skip_ows(raw, 1) 195 | kn = CSval(raw) 196 | skip_ows(raw) 197 | if len(raw[0]) > 0 and raw[0][0] == "=": 198 | skip_ows(raw, 1) 199 | kv = CSval(raw) 200 | skip_ows(raw) 201 | else: 202 | kv = None 203 | dc[kn] = kv 204 | 205 | if len(raw[0]) == 0: 206 | break 207 | if raw[0][0] == ",": 208 | skip_ows(raw, 1) 209 | continue 210 | if raw[0][0] != ";": 211 | raise Error("Expected EOL, comma or semicolon") 212 | assert len(raw[0]) == 0 213 | 214 | def dump(self): 215 | print("Input string:\t\t%s" % self.input) 216 | print("") 217 | print("Self-identified:\t%s" % self.self_identified) 218 | print("Header-name:\t\t%s" % self.field_name) 219 | for dn,dc in self.dicts: 220 | print("\tDict\t\t%s" % dn) 221 | for kn,kv in dc.iteritems(): 222 | print("\t\t\t\t%s: " % kn, kv) 223 | 224 | 225 | for j in ( 226 | # RFC7231 5.3.2 227 | "Accept: audio/*; q=0.2, audio/basic", 228 | "Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c", 229 | 230 | # RFC7231 5.3.3 231 | "Accept-Charset: iso-8859-5, unicode-1-1;q=0.8", 232 | 233 | # RFC7231 5.3.4 234 | "Accept-Encoding: compress, gzip", 235 | "Accept-Encoding:", 236 | "Accept-Encoding: *", 237 | "Accept-Encoding: compress;q=0.5, gzip;q=1.0", 238 | "Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0", 239 | 240 | # RFC7231 5.3.5 241 | "Accept-Language: da, en-gb;q=0.8, en;q=0.7", 242 | 243 | # RFC7234 5.1 [constructed example] 244 | "Age: 12345", 245 | 246 | # RFC7231 7.4.1 247 | "Allow: GET, HEAD, PUT", 248 | 249 | # RFC7230 6.1 250 | "Connection: close", 251 | 252 | # RFC7231 3.1.2.2 253 | "Content-Encoding: gzip", 254 | 255 | # RFC7231 3.1.3.2 256 | "Content-Language: da", 257 | "Content-Language: mi, en", 258 | 259 | # RFC7230 3.3.2 260 | "Content-Length: 3495", 261 | 262 | # RFC7231 3.1.1.5 263 | "Content-Type: text/html; charset=ISO-8859-4", 264 | 265 | # RFC7231 5.1.1 266 | "Expect: 100-continue", 267 | 268 | # RFC7231 5.1.2 [constructed example] 269 | "Max-Forwards: 34", 270 | 271 | # RFC7231 Appendix A XXX:TODO 272 | 273 | # RFC7230 4.3 274 | "TE: deflate", 275 | "TE:", 276 | "TE: trailers, deflate;q=0.5", 277 | 278 | # RFC7230 4.4 [constructed example] 279 | "Trailer: Bogo-Header", 280 | 281 | # RFC7230 3.3.1 282 | "Transfer-Encoding: gzip, chunked", 283 | 284 | # RFC7230 6.7 285 | "Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11", 286 | 287 | # RFC7231 7.1.4 288 | "Vary: accept-encoding, accept-language", 289 | 290 | ############################################################### 291 | # Constructed examples 292 | ############################################################### 293 | 294 | # h1-ascii-string 295 | 'cx1: tell-them;txt="foobar"', 296 | 297 | # h1-unicode-string 298 | '''cx2: tell-them;txt="foobar\u'1F4A9'\u'08'\u'1F574'"''', 299 | 300 | # h1-blob 301 | 'cx3: dont-tell-them;txt=:SGVsbG8gV29ybGQK:', 302 | 303 | 'cx4: >dont-tell-them;txt=:SGVsbG8gV29ybGQK: <', 304 | 305 | ): 306 | c = Cshdr(j) 307 | print("-" * 72) 308 | c.dump() 309 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-cdn-loop.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Loop Detection in Content Delivery Networks (CDNs) 3 | docname: draft-ietf-httpbis-cdn-loop-latest 4 | category: std 5 | abbrev: CDN Loop Detection 6 | ipr: trust200902 7 | area: Applications and Real-Time 8 | workgroup: HTTP 9 | keyword: Internet-Draft 10 | stand_alone: yes 11 | pi: [toc, sortrefs, symrefs] 12 | 13 | author: 14 | - 15 | ins: S. Ludin 16 | name: Stephen Ludin 17 | organization: Akamai Technologies 18 | email: sludin@akamai.com 19 | - 20 | ins: M. Nottingham 21 | name: Mark Nottingham 22 | organization: Fastly 23 | email: mnot@fastly.com 24 | - 25 | ins: N. Sullivan 26 | name: Nick Sullivan 27 | organization: Cloudflare 28 | email: nick@cloudflare.com 29 | 30 | normative: 31 | RFC2119: 32 | 33 | informative: 34 | loop-attack: 35 | title: Forwarding-Loop Attacks in Content Delivery Networks 36 | author: 37 | - name: Jianjun Chen 38 | - name: Jian Jiang 39 | - name: Xiaofeng Zheng 40 | - name: Haixin Duan 41 | - name: Jinjin Liang 42 | - name: Kang Li 43 | - name: Tao Wan 44 | - name: Vern Paxson 45 | date: 2016/02/21 46 | seriesinfo: 47 | target: http://www.icir.org/vern/papers/cdn-loops.NDSS16.pdf 48 | 49 | 50 | 51 | --- abstract 52 | 53 | This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational 54 | need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks 55 | (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a 56 | non-terminating loop. The new header field can be used to identify the error and terminate the loop. 57 | 58 | --- middle 59 | 60 | # Introduction 61 | 62 | In modern deployments of HTTP servers, it is common to interpose Content Delivery Networks (CDNs) 63 | in front of origin servers to improve latency perceived by end users, reduce operational costs, and 64 | improve scalability and reliability of services. 65 | 66 | Often, more than one CDN is in use by a given origin. This happens for a variety of reasons, such 67 | as cost savings, arranging for failover should one CDN have issues, or direct comparison 68 | of the CDNs' services. 69 | 70 | As a result, it is possible for forwarding CDNs to be configured in a "loop" accidentally; 71 | because routing is achieved through a combination of DNS and forwarding rules, and site 72 | configurations are sometimes complex and managed by several parties. 73 | 74 | When this happens, it is difficult to debug. Additionally, it sometimes isn't accidental; loops 75 | between multiple CDNs can be used as an attack vector (e.g., see {{loop-attack}}), especially if one 76 | CDN unintentionally strips the loop detection headers of another. 77 | 78 | This specification defines the CDN-Loop HTTP request header field to help 79 | detect such attacks and accidents among forwarding CDNs that have implemented 80 | it; the header field may not be modified by their customers. 81 | 82 | ## Relationship to Via 83 | 84 | HTTP defines the Via header field in Section 5.7.1 of {{!RFC7230}} for "tracking message forwards, 85 | avoiding request loops, and identifying the protocol capabilities of senders along the 86 | request/response chain." 87 | 88 | In theory, Via could be used to identify these loops. However, in practice it is not used in this 89 | fashion, because some HTTP servers use Via for other purposes -- in particular, some 90 | implementations disable some HTTP/1.1 features when the Via header is present. 91 | 92 | 93 | ## Conventions and Definitions 94 | 95 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 96 | "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as 97 | described in BCP 14 {{RFC2119}} {{!RFC8174}} when, and only when, they appear in all capitals, as 98 | shown here. 99 | 100 | This specification uses the Augmented Backus-Naur Form (ABNF) notation of {{!RFC5234}} with a list 101 | extension, defined in Section 7 of {{!RFC7230}}, that allows for compact definition of 102 | comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). 103 | Additionally, it uses a token (OWS), uri-host, and port rules from {{!RFC7230}} and the parameter 104 | rule from {{!RFC7231}}. 105 | 106 | 107 | # The CDN-Loop Request Header Field {#header} 108 | 109 | The CDN-Loop request header field is intended to help a Content Delivery Network identify when an incoming request has already passed through that CDN's servers to detect loops. 110 | 111 | ~~~ abnf 112 | CDN-Loop = #cdn-info 113 | cdn-info = cdn-id *( OWS ";" OWS parameter ) 114 | cdn-id = ( uri-host [ ":" port ] ) / pseudonym 115 | pseudonym = token 116 | ~~~ 117 | 118 | The cdn-id identifies the CDN using either a hostname under its control or a pseudonym. Hostnames 119 | are preferred, to help avoid accidental collisions. If a pseudonym is used, unintentional collisions are more likely, and therefore values should be carefully chosen to prevent them; for example, using a well-known value (such as the recognized name of the CDN in question), or a generated value with enough entropy to make collisions unlikely (such as a UUID {{?RFC4122}}). 120 | 121 | Optionally, cdn-info can have semicolon-separated key/value parameters to accommodate additional 122 | information for the CDN's use. 123 | 124 | Conforming Content Delivery Networks SHOULD add a cdn-info to this header field in all requests they 125 | generate or forward (creating the header field if necessary). 126 | 127 | As with all HTTP header fields defined using the "#" rule, the CDN-Loop header field can be added to by comma-separating values, or by creating a new header field with the desired value. 128 | 129 | For example: 130 | 131 | ~~~ example 132 | GET /image.jpg HTTP/1.1 133 | Host: cdn-customer.example 134 | User-Agent: ExampleBrowser/5 135 | CDN-Loop: foo123.foocdn.example, barcdn.example; trace="abcdef" 136 | CDN-Loop: AnotherCDN; abc=123; def="456" 137 | 138 | ~~~ 139 | 140 | Note that the pseudonym syntax does not allow whitespace, DQUOTE, or any of the characters 141 | "(),/:;<=>?@[\]{}". See Section 3.2.6 of {{!RFC7230}}. Likewise, note the rules for when parameter 142 | values need to be quoted in Section 3.1.1 of {{!RFC7231}}. 143 | 144 | The effectiveness of this mechanism relies on all intermediaries preserving the header field, since 145 | removing (or allowing it to be removed, e.g., by customer configuration) would prevent downstream 146 | CDNs from using it to detect looping. In general, unknown header fields are not removed by 147 | intermediaries, but there may be a need to add CDN-Loop to an implementation's list of header fields 148 | that are not to be removed under any circumstances. The header field SHOULD NOT be used for other 149 | purposes. 150 | 151 | # Security Considerations 152 | 153 | The threat model that the CDN-Loop header field addresses is a customer who is attacking a service 154 | provider by configuring a forwarding loop by accident or malice. For it to function, CDNs cannot 155 | allow customers to modify or remove it in their configuration (see {{header}}). 156 | 157 | Note that a CDN that allows customers to remove or modify the CDN-Loop header field (i.e., they do 158 | not implement this specification) remains an attack vector against both implementing and 159 | non-implementing CDNs. 160 | 161 | A CDN's use of the CDN-Loop header field might expose its presence. For example, if CDN A is configured to forward its requests to CDN B for a given origin, CDN B's presence can be revealed if it behaves differently based upon the presence of the CDN-Loop header field. 162 | 163 | The CDN-Loop header field can be generated by any client, and therefore its contents cannot be 164 | trusted. CDNs who modify their behavior based upon its contents should assure that this does not 165 | become an attack vector (e.g., for Denial of Service). 166 | 167 | It is possible to sign the contents of the header field (either by putting the signature directly 168 | into the field's content or using another header field), but such use is not defined (or required) 169 | by this specification. 170 | 171 | Depending on how it is used, CDN-Loop can expose information about the internal configuration of the CDN; for example, the number of hops inside the CDN, and the hostnames of nodes. 172 | 173 | 174 | # IANA Considerations 175 | 176 | This document registers the "CDN-Loop" header field in the "Permanent Message Header Field Names" registry. 177 | 178 | * Header Field Name: CDN-Loop 179 | * Protocol: http 180 | * Status: standard 181 | * Reference: RFC 8586 182 | 183 | 184 | --- back 185 | 186 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-cookie-prefixes.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cookie Prefixes 3 | docname: draft-ietf-httpbis-cookie-prefixes-00 4 | date: 2017 5 | category: std 6 | updates: 6265 7 | 8 | ipr: trust200902 9 | area: Applications and Real-Time 10 | workgroup: HTTP 11 | keyword: Internet-Draft 12 | keyword: Cookie 13 | 14 | stand_alone: yes 15 | pi: [toc, tocindent, sortrefs, symrefs, strict, compact, subcompact, comments, inline] 16 | 17 | author: 18 | - 19 | ins: M. West 20 | name: Mike West 21 | organization: Google, Inc 22 | email: mkwst@google.com 23 | uri: https://mikewest.org/ 24 | 25 | normative: 26 | RFC2119: 27 | RFC3986: 28 | RFC6265: 29 | 30 | informative: 31 | RFC2109: 32 | POWERFUL-FEATURES: 33 | target: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features 34 | title: "Prefer Secure Origins for Powerful New Features" 35 | date: 2015 36 | author: 37 | ins: C. Palmer 38 | name: Chris Palmer 39 | 40 | SECURE-CONTEXTS: 41 | target: https://w3c.github.io/webappsec-secure-contexts/ 42 | title: "Secure Contexts" 43 | date: 2016 44 | author: 45 | ins: M. West 46 | name: Mike West 47 | 48 | DEPRECATING-HTTP: 49 | target: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ 50 | title: "Deprecating Non-Secure HTTP" 51 | date: 2015-04-30 52 | author: 53 | ins: R. Barnes 54 | name: Richard Barnes 55 | 56 | Lawrence2015: 57 | target: http://textslashplain.com/2015/10/09/duct-tape-and-baling-wirecookie-prefixes/ 58 | title: "Duct Tape and Baling Wire -- Cookie Prefixes" 59 | date: 2015-10-09 60 | author: 61 | ins: E. Lawrence 62 | name: Eric Lawrence 63 | 64 | --- abstract 65 | 66 | This document updates RFC6265 by adding a set of restrictions upon the names 67 | which may be used for cookies with specific properties. These restrictions 68 | enable user agents to smuggle cookie state to the server within the confines 69 | of the existing `Cookie` request header syntax, and limits the ways in which 70 | cookies may be abused in a conforming user agent. 71 | 72 | --- note_Note_to_Readers 73 | 74 | Discussion of this draft takes place on the HTTP working group mailing list 75 | (ietf-http-wg@w3.org), which is archived at . 76 | 77 | Working Group information can be found at ; source 78 | code and issues list for this draft can be found at . 79 | 80 | --- middle 81 | 82 | # Introduction 83 | 84 | Section 8.5 and Section 8.6 of {{RFC6265}} spell out some of the drawbacks of 85 | cookies' implementation: due to historical accident, it is impossible for a 86 | server to have confidence that a cookie set in a secure way (e.g., as a 87 | domain cookie with the `Secure` (and possibly `HttpOnly`) flags set) remains 88 | intact and untouched by non-secure subdomains. 89 | 90 | We can't alter the syntax of the `Cookie` request header, as that would likely 91 | break a number of implementations. This rules out sending a cookie's flags along 92 | with the cookie directly, but we can smuggle information along with the cookie 93 | if we reserve certain name prefixes for cookies with certain properties. 94 | 95 | This document describes such a scheme, which enables servers to set cookies 96 | which conforming user agents will ensure are `Secure`, and locked to a domain. 97 | 98 | # Terminology and notation 99 | 100 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 101 | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 102 | interpreted as described in {{RFC2119}}. 103 | 104 | The `scheme` component of a URI is defined in Section 3 of {{RFC3986}}. 105 | 106 | # Prefixes 107 | 108 | ## The "__Secure-" prefix 109 | 110 | If a cookie's name begins with "__Secure-", the cookie MUST be: 111 | 112 | 1. Set with a `Secure` attribute 113 | 114 | 2. Set from a URI whose `scheme` is considered "secure" by the user agent. 115 | 116 | The following cookie would be rejected when set from any origin, as the `Secure` 117 | flag is not set 118 | 119 | Set-Cookie: __Secure-SID=12345; Domain=example.com 120 | 121 | While the following would be accepted if set from a secure origin (e.g. 122 | `https://example.com/`), and rejected otherwise: 123 | 124 | Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com 125 | 126 | ## The "__Host-" prefix 127 | 128 | If a cookie's name begins with "__Host-", the cookie MUST be: 129 | 130 | 1. Set with a `Secure` attribute 131 | 132 | 2. Set from a URI whose `scheme` is considered "secure" by the user agent. 133 | 134 | 3. Sent only to the host which set the cookie. That is, a cookie named 135 | "__Host-cookie1" set from `https://example.com` MUST NOT contain a `Domain` 136 | attribute (and will therefore be sent only to `example.com`, and not to 137 | `subdomain.example.com`). 138 | 139 | 4. Sent to every request for a host. That is, a cookie named "__Host-cookie1" 140 | MUST contain a `Path` attribute with a value of "/". 141 | 142 | The following cookies would always be rejected: 143 | 144 | Set-Cookie: __Host-SID=12345 145 | Set-Cookie: __Host-SID=12345; Secure 146 | Set-Cookie: __Host-SID=12345; Domain=example.com 147 | Set-Cookie: __Host-SID=12345; Domain=example.com; Path=/ 148 | Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/ 149 | 150 | While the following would be accepted if set from a secure origin (e.g. 151 | `https://example.com/`), and rejected otherwise: 152 | 153 | Set-Cookie: __Host-SID=12345; Secure; Path=/ 154 | 155 | # User Agent Requirements 156 | 157 | This document updates Section 5.3 of {{RFC6265}} as follows: 158 | 159 | After step 10 of the current algorithm, the cookies flags are set. Insert the 160 | following steps to perform the prefix checks this document specifies: 161 | 162 | 11. If the `cookie-name` begins with the string "__Secure-" or "__Host-", 163 | abort these steps and ignore the cookie entirely unless both of the 164 | following conditions are true: 165 | 166 | * The cookie's `secure-only-flag` is `true` 167 | 168 | * `request-uri`'s `scheme` component denotes a "secure" protocol (as 169 | determined by the user agent) 170 | 171 | 12. If the `cookie-name` begins with the string "__Host-", abort these 172 | steps and ignore the cookie entirely unless the following conditions are 173 | true: 174 | 175 | * The cookie's `host-only-flag` is `true` 176 | 177 | * The cookie's `path` is "/" 178 | 179 | # Aesthetic Considerations 180 | 181 | ## Not pretty. 182 | 183 | Prefixes are ugly. :( 184 | 185 | ## Why "__"? 186 | 187 | We started with `$`, but ran into issues with servers that had implemented 188 | {{RFC2109}}-style cookies. `__` is a prefix used for a number of well-known 189 | cookies in the wild (notably Google Analytics's `__ut*` cookies, and 190 | CloudFlare's `__cfduid`), and so is unlikely to produce such compatibility 191 | issues, while being uncommon enough to mitigate the risk of collisions. 192 | 193 | # Security Considerations 194 | 195 | ## Secure Origins Only 196 | 197 | It would certainly be possible to extend this scheme to non-secure origins (and 198 | an earlier draft of this document did exactly that). User agents, however, are 199 | slowly moving towards a world where features with security implications are 200 | available only over secure transport (see {{SECURE-CONTEXTS}}, 201 | {{POWERFUL-FEATURES}}, and {{DEPRECATING-HTTP}}). This document follows that 202 | trend, limiting exciting new cookie properties to secure transport in order to 203 | ensure that user agents can make claims which middlemen will have a hard time 204 | violating. 205 | 206 | To that end, note that the requirements listed above mean that prefixed cookies 207 | will be rejected entirely if a non-secure origin attempts to set them. 208 | 209 | ## Limitations 210 | 211 | This scheme gives no assurance to the server that the restrictions on cookie 212 | names are enforced. Servers could certainly probe the user agent's functionality 213 | to determine support, or sniff based on the `User-Agent` request header, if 214 | such assurances were deemed necessary. 215 | 216 | --- back 217 | 218 | # Acknowledgements 219 | 220 | Eric Lawrence had this idea a million years ago, and wrote about its genesis in 221 | {{Lawrence2015}}. Devdatta Akhawe helped justify the potential impact of the 222 | scheme on real-world websites. Thomas Broyer pointed out the issues with a 223 | leading `$` in the prefixes, and Brian Smith provided valuable contributions to 224 | the discussion around a replacement (ISO C indeed). 225 | -------------------------------------------------------------------------------- /writeups/compression-dictionary.md: -------------------------------------------------------------------------------- 1 | # Document Shepherd Write-Up for Group Documents 2 | 3 | *This version is dated 4 July 2022.* 4 | 5 | Thank you for your service as a document shepherd. Among the responsibilities is 6 | answering the questions in this write-up to give helpful context to Last Call 7 | and Internet Engineering Steering Group ([IESG][1]) reviewers, and your 8 | diligence in completing it is appreciated. The full role of the shepherd is 9 | further described in [RFC 4858][2]. You will need the cooperation of the authors 10 | and editors to complete these checks. 11 | 12 | Note that some numbered items contain multiple related questions; please be sure 13 | to answer all of them. 14 | 15 | ## Document History 16 | 17 | 1. Does the working group (WG) consensus represent the strong concurrence of a 18 | few individuals, with others being silent, or did it reach broad agreement? 19 | 20 | _Fairly broad agreement._ 21 | 22 | 2. Was there controversy about particular points, or were there decisions where 23 | the consensus was particularly rough? 24 | 25 | _There was some discussion of how many compression algorithms to include. Although there were diverse opinions, we converged on the approach taken in the draft._ 26 | 27 | 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If 28 | so, please summarize the areas of conflict in separate email messages to the 29 | responsible Area Director. (It should be in a separate email because this 30 | questionnaire is publicly available.) 31 | 32 | _No._ 33 | 34 | 4. For protocol documents, are there existing implementations of the contents of 35 | the document? Have a significant number of potential implementers indicated 36 | plans to implement? Are any existing implementations reported somewhere, 37 | either in the document itself (as [RFC 7942][3] recommends) or elsewhere 38 | (where)? 39 | 40 | _Yes; Chrome has implemented on the client side, and several parties have indicated interest and/or intent to implement on the server side._ 41 | 42 | ## Additional Reviews 43 | 44 | 5. Do the contents of this document closely interact with technologies in other 45 | IETF working groups or external organizations, and would it therefore benefit 46 | from their review? Have those reviews occurred? If yes, describe which 47 | reviews took place. 48 | 49 | _Yes; there are browser-specific implementation considerations that have been coordinated with the W3C and WHATWG._ 50 | 51 | 6. Describe how the document meets any required formal expert review criteria, 52 | such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 53 | 54 | *Routine HTTP-related registry reviews need to happen as part of IETF LC; no issues anticipated.* 55 | 56 | 7. If the document contains a YANG module, has the final version of the module 57 | been checked with any of the [recommended validation tools][4] for syntax and 58 | formatting validation? If there are any resulting errors or warnings, what is 59 | the justification for not fixing them at this time? Does the YANG module 60 | comply with the Network Management Datastore Architecture (NMDA) as specified 61 | in [RFC 8342][5]? 62 | 63 | _No YANG here._ 64 | 65 | 8. Describe reviews and automated checks performed to validate sections of the 66 | final version of the document written in a formal language, such as XML code, 67 | BNF rules, MIB definitions, CBOR's CDDL, etc. 68 | 69 | *HTTP structured fields syntax have been checked with a linter.* 70 | 71 | 72 | ## Document Shepherd Checks 73 | 74 | 9. Based on the shepherd's review of the document, is it their opinion that this 75 | document is needed, clearly written, complete, correctly designed, and ready 76 | to be handed off to the responsible Area Director? 77 | 78 | _Yes._ 79 | 80 | 10. Several IETF Areas have assembled [lists of common issues that their 81 | reviewers encounter][6]. For which areas have such issues been identified 82 | and addressed? For which does this still need to happen in subsequent 83 | reviews? 84 | 85 | _N/A._ 86 | 87 | 11. What type of RFC publication is being requested on the IETF stream ([Best 88 | Current Practice][12], [Proposed Standard, Internet Standard][13], 89 | [Informational, Experimental or Historic][14])? Why is this the proper type 90 | of RFC? Do all Datatracker state attributes correctly reflect this intent? 91 | 92 | _Proposed Standard. This is appropriate for a new protocol specification with some implementation._ 93 | 94 | 12. Have reasonable efforts been made to remind all authors of the intellectual 95 | property rights (IPR) disclosure obligations described in [BCP 79][7]? To 96 | the best of your knowledge, have all required disclosures been filed? If 97 | not, explain why. If yes, summarize any relevant discussion, including links 98 | to publicly-available messages when applicable. 99 | 100 | _Yes; they have been reminded._ 101 | 102 | 13. Has each author, editor, and contributor shown their willingness to be 103 | listed as such? If the total number of authors and editors on the front page 104 | is greater than five, please provide a justification. 105 | 106 | _Yes._ 107 | 108 | 14. Document any remaining I-D nits in this document. Simply running the [idnits 109 | tool][8] is not enough; please review the ["Content Guidelines" on 110 | authors.ietf.org][15]. (Also note that the current idnits tool generates 111 | some incorrect warnings; a rewrite is underway.) 112 | 113 | See discussion of downreferences. 114 | 115 | 15. Should any informative references be normative or vice-versa? See the [IESG 116 | Statement on Normative and Informative References][16]. 117 | 118 | RFC5861 can be made informative. 119 | 120 | 16. List any normative references that are not freely available to anyone. Did 121 | the community have sufficient access to review any such normative 122 | references? 123 | 124 | _N/A._ 125 | 126 | 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 127 | 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, 128 | list them. 129 | 130 | RFC5861 is a downwards reference, but can be made informative. 131 | 132 | 18. Are there normative references to documents that are not ready to be 133 | submitted to the IESG for publication or are otherwise in an unclear state? 134 | If so, what is the plan for their completion? 135 | 136 | _No._ 137 | 138 | 19. Will publication of this document change the status of any existing RFCs? If 139 | so, does the Datatracker metadata correctly reflect this and are those RFCs 140 | listed on the title page, in the abstract, and discussed in the 141 | introduction? If not, explain why and point to the part of the document 142 | where the relationship of this document to these other RFCs is discussed. 143 | 144 | _No._ 145 | 146 | 20. Describe the document shepherd's review of the IANA considerations section, 147 | especially with regard to its consistency with the body of the document. 148 | Confirm that all aspects of the document requiring IANA assignments are 149 | associated with the appropriate reservations in IANA registries. Confirm 150 | that any referenced IANA registries have been clearly identified. Confirm 151 | that each newly created IANA registry specifies its initial contents, 152 | allocations procedures, and a reasonable name (see [RFC 8126][11]). 153 | 154 | _The requests appear to be correct._ 155 | 156 | 21. List any new IANA registries that require Designated Expert Review for 157 | future allocations. Are the instructions to the Designated Expert clear? 158 | Please include suggestions of designated experts, if appropriate. 159 | 160 | _N/A._ 161 | 162 | 163 | [1]: https://www.ietf.org/about/groups/iesg/ 164 | [2]: https://www.rfc-editor.org/rfc/rfc4858.html 165 | [3]: https://www.rfc-editor.org/rfc/rfc7942.html 166 | [4]: https://wiki.ietf.org/group/ops/yang-review-tools 167 | [5]: https://www.rfc-editor.org/rfc/rfc8342.html 168 | [6]: https://wiki.ietf.org/group/iesg/ExpertTopics 169 | [7]: https://www.rfc-editor.org/info/bcp79 170 | [8]: https://www.ietf.org/tools/idnits/ 171 | [9]: https://www.rfc-editor.org/rfc/rfc3967.html 172 | [10]: https://www.rfc-editor.org/info/bcp97 173 | [11]: https://www.rfc-editor.org/rfc/rfc8126.html 174 | [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 175 | [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 176 | [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 177 | [15]: https://authors.ietf.org/en/content-guidelines-overview 178 | [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ 179 | [17]: https://datatracker.ietf.org/doc/downref/ 180 | 181 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-cookie-alone.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Deprecate modification of 'secure' cookies from non-secure origins 3 | abbrev: Leave Secure Cookies Alone 4 | docname: draft-ietf-httpbis-cookie-alone-latest 5 | date: 2017 6 | category: std 7 | updates: 6265 8 | 9 | ipr: trust200902 10 | area: Applications and Real-Time 11 | workgroup: HTTP 12 | keyword: Internet-Draft 13 | keyword: Cookie 14 | 15 | stand_alone: yes 16 | pi: [toc, tocindent, sortrefs, symrefs, strict, compact, subcompact, comments, inline] 17 | 18 | author: 19 | - 20 | ins: M. West 21 | name: Mike West 22 | organization: Google, Inc 23 | email: mkwst@google.com 24 | uri: https://mikewest.org/ 25 | 26 | normative: 27 | RFC2119: 28 | RFC3986: 29 | RFC6265: 30 | 31 | informative: 32 | COOKIE-INTEGRITY: 33 | target: https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng 34 | title: "Cookies Lack Integrity: Real-World Implications" 35 | date: 2015-08 36 | author: 37 | - 38 | ins: X. Zheng 39 | name: Xiaofeng Zheng 40 | organization: Tsinghua University and Tsinghua National Laboratory for Information Science and Technology 41 | - 42 | ins: J. Jiang 43 | name: Jian Jiang 44 | organization: University of California, Berkeley 45 | - 46 | ins: J. Liang 47 | name: Jinjin Liang 48 | organization: Tsinghua University and Tsinghua National Laboratory for Information Science and Technology; 49 | - 50 | ins: H. Duan 51 | name: Haixin Duan 52 | organization: Tsinghua University, Tsinghua National Laboratory for Information Science and Technology, and International Computer Science Institute; 53 | - 54 | ins: S. Chen 55 | name: Shuo Chen 56 | organization: Microsoft Research Redmond; 57 | - 58 | ins: T. Wan 59 | name: Tao Wan 60 | organization: Huawei Canada 61 | - 62 | ins: N. Weaver 63 | name: Nicholas Weaver 64 | organization: International Computer Science Institute and University of California, Berkeley 65 | COOKIE-PREFIXES: 66 | target: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes 67 | title: "Cookie Prefixes" 68 | date: 2016 69 | author: 70 | - 71 | ins: M. West 72 | name: Mike West 73 | organization: Google, Inc 74 | HSTS-PRELOADING: 75 | target: https://hstspreload.appspot.com/ 76 | title: "HSTS Preload Submission" 77 | RFC6797: 78 | 79 | --- abstract 80 | 81 | This document updates RFC6265 by removing the ability for a non-secure origin 82 | to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' 83 | flag is set. This deprecation improves the isolation between HTTP and HTTPS 84 | origins, and reduces the risk of malicious interference. 85 | 86 | --- note_Note_to_Readers 87 | 88 | Discussion of this draft takes place on the HTTP working group mailing list 89 | (ietf-http-wg@w3.org), which is archived at . 90 | 91 | Working Group information can be found at ; source 92 | code and issues list for this draft can be found at . 93 | 94 | --- middle 95 | 96 | # Introduction 97 | 98 | Section 8.5 and Section 8.6 of {{RFC6265}} spell out some of the drawbacks of 99 | cookies' implementation: due to historical accident, non-secure origins can set 100 | cookies which will be delivered to secure origins in a manner indistinguishable 101 | from cookies set by that origin itself. This enables a number of attacks, which 102 | have been recently spelled out in some detail in {{COOKIE-INTEGRITY}}. 103 | 104 | We can mitigate the risk of these attacks by making it more difficult for 105 | non-secure origins to influence the state of secure origins. Accordingly, this 106 | document recommends the deprecation and removal of non-secure origins' ability 107 | to write cookies with a 'secure' flag, and their ability to overwrite cookies 108 | whose 'secure' flag is set. 109 | 110 | # Terminology and notation 111 | 112 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 113 | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 114 | interpreted as described in {{RFC2119}}. 115 | 116 | The `scheme` component of a URI is defined in Section 3 of {{RFC3986}}. 117 | 118 | # Recommendations 119 | 120 | This document updates Section 5.3 of {{RFC6265}} as follows: 121 | 122 | 1. After step 8 of the current algorithm, which sets the cookie's 123 | `secure-only-flag`, execute the following step: 124 | 125 | 9. If the `scheme` component of the `request-uri` does not denote a 126 | "secure" protocol (as defined by the user agent), and the cookie's 127 | `secure-only-flag` is `true`, then abort these steps and ignore the 128 | newly created cookie entirely. 129 | 130 | 2. Before step 11, execute the following step: 131 | 132 | 11. If the newly created cookie's `secure-only-flag` is not set, and the 133 | `scheme` component of the `request-uri` does not denote a "secure" 134 | protocol, then abort these steps and ignore the newly created cookie 135 | entirely if the cookie store contains one or more cookies that meet all 136 | of the following criteria: 137 | 138 | 1. Their `name` matches the `name` of the newly created cookie. 139 | 140 | 2. Their `secure-only-flag` is set. 141 | 142 | 3. Their `domain` domain-matches the `domain` of the newly created 143 | cookie, or vice-versa. 144 | 145 | 4. The `path` of the newly created cookie path-matches the `path` 146 | of the existing cookie. 147 | 148 | Note: The `path` comparison is not symmetric, ensuring only that a 149 | newly-created non-secure cookie does not overlay an existing secure 150 | cookie, providing some mitigation against cookie fixing attacks. 151 | That is, given an existing secure cookie named `a` with a `path` of 152 | `/login`, a non-secure cookie named `a` could be set for a `path` 153 | of `/` or `/foo`, but not for a `path` of `/login` or `/login/en`. 154 | 155 | Note: This allows "secure" pages to override `secure` cookies with 156 | non-secure variants. Perhaps we should restrict that as well? 157 | 158 | 3. In order to ensure that a non-secure site can never cause a `secure` cookie 159 | to be evicted, adjust the "remove excess cookies" priority order at the 160 | bottom of Section 5.3 to be the following: 161 | 162 | 1. Expired cookies. 163 | 164 | 2. Cookies whose `secure-only-flag` is not set and which share a 165 | `domain` field with more than a predetermined number of other cookies. 166 | 167 | 3. Cookies that share a `domain` field with more than a predetermined 168 | number of other cookies. 169 | 170 | 4. All cookies. 171 | 172 | Note that the eviction algorithm specified here is triggered only after 173 | insertion of a cookie which causes the user agent to exceed some 174 | predetermined upper bound. Conforming user agents MUST ensure that inserting 175 | a non-secure cookie does not cause a secure cookie to be removed. 176 | 177 | # Security Considerations 178 | 179 | This specification increases a site's confidence that secure cookies it sets 180 | will remain unmodified by insecure pages on hosts which it domain-matches. 181 | Ideally, sites would use HSTS as described in {{RFC6797}} to defend more 182 | robustly against the dangers of non-secure transport in general, but until 183 | adoption of that protection becomes ubiquitous, this deprecation this document 184 | recommends will mitigate a number of risks. 185 | 186 | The mitigations in this document do not, however, give complete confidence that 187 | a given cookie was set securely. If an attacker is able to impersonate a 188 | response from `http://example.com/` before a user visits `https://example.com/`, 189 | the user agent will accept any cookie that the insecure origin sets, as the 190 | "secure" cookie won't yet be present in the user agent's cookie store. An 191 | active network attacker may still be able to use this ability to mount an attack 192 | against `example.com`, even if that site uses HTTPS exclusively. 193 | 194 | The proposal in {{COOKIE-PREFIXES}} could mitigate this risk, as could 195 | "preloading" HSTS for `example.com` into the user agent {{HSTS-PRELOADING}}. 196 | 197 | --- back 198 | 199 | # Acknowledgements 200 | 201 | Richard Barnes encouraged a formalization of the deprecation proposal. 202 | {{COOKIE-INTEGRITY}} was a useful exploration of the issues {{RFC6265}} 203 | described. 204 | 205 | # Changes 206 | 207 | ## Since -00 208 | 209 | * Issue 223 addressed by adding a path-match constraint to the storage algorithm 210 | for non-secure cookies. This ensures that non-secure cookies cannot overlay 211 | secure cookies for a given path, but allows secure and non-secure cookies with 212 | the same name to exist on distinct paths. 213 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-legally-restricted-status.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 | 10 | ]> 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 27 | 28 | 29 | An HTTP Status Code to Report Legal Obstacles 30 | 31 | Textuality 32 |
33 | tbray@textuality.com 34 | http://www.tbray.org/ongoing/ 35 |
36 | 37 | 38 | 39 | Applications and Real-Time 40 | HTTP 41 | HTTP 42 | 43 | 44 | 45 | This document specifies a Hypertext Transfer Protocol (HTTP) 46 | status code for use when resource access is denied as a 47 | consequence of legal demands. 48 | 49 | 50 | 51 | 52 | 53 | Discussion of this draft takes place on the HTTPBIS working group mailing list 54 | (ietf-http-wg@w3.org), which is archived at . 56 | 57 | 58 | Working Group information can be found at 60 | and ; source code and issues 61 | list for this draft can be found at 62 | . 63 | 64 | 67 | 68 | 69 | 70 | 71 | 72 |
73 | This document specifies a Hypertext Transfer Protocol (HTTP) 74 | status code for use when a server operator has received a legal 75 | demand to deny access to a resource or to a set of resources which 76 | includes the requested resource. 77 | 78 | This status code can be used to provide transparency 79 | in circumstances where issues of law or public policy affect server 80 | operations. This transparency may be beneficial both to these operators 81 | and to end users. 82 | discusses the forces working 83 | against transparent operation of the Internet; these clearly include 84 | legal interventions to restrict access to content. As that document 85 | notes, and as Section 4 of states, such 86 | restrictions should be made explicit. 87 | 88 | Feedback should occur on the ietf-http-wg@w3.org mailing list. 89 |
90 | 91 |
92 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 93 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 94 | this document are to be interpreted as described in . 96 |
97 | 98 | 99 |
100 | This status code indicates that the server is denying access 101 | to the resource as a consequence of a legal demand. 102 | 103 | The server in question might not be an origin server. This type of 104 | legal demand typically most directly affects the operations of ISPs and 105 | search engines. 106 | 107 | Responses using this status code SHOULD include an explanation, 108 | in the response body, of the details of the legal demand: the party 109 | making it, the applicable legislation or regulation, and what classes of 110 | person and resource it applies 111 | to. For example: 112 | 113 |
114 | HTTP/1.1 451 Unavailable For Legal Reasons 115 | Link: <https://spqr.example.org/legislatione>; rel="blocked-by" 116 | Content-Type: text/html 117 | 118 | <html> 119 | <head><title>Unavailable For Legal Reasons</title></head> 120 | <body> 121 | <h1>Unavailable For Legal Reasons</h1> 122 | <p>This request may not be serviced in the Roman Province 123 | of Judea due to the Lex Julia Majestatis, which disallows 124 | access to resources hosted on servers deemed to be 125 | operated by the People's Front of Judea.</p> 126 | </body> 127 | </html>
128 | 129 | The use of the 451 status code implies neither the existence nor 130 | non-existence of the resource named in the request. That is to say, 131 | it is possible that if the legal demands were removed, 132 | a request for the resource still might not succeed. 133 | 134 | Note that in many cases clients can still access the denied resource by 135 | using technical countermeasures such as a VPN or the Tor network. 136 | 137 | A 451 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls; see . 138 |
139 | 140 |
141 | As noted above, when an attempt to access a resource fails 142 | with status 451, the entity blocking access might or might not be the 143 | origin server. There are a variety of entities in the resource-access 144 | path which could choose to deny access, for example ISPs, 145 | cache providers, and DNS servers. 146 | It is useful, when legal blockages occur, to be able to identify the 147 | entities actually implementing the blocking. 148 | When an entity blocks access to a resource and returns status 451, it 149 | SHOULD include a "Link" HTTP header field 150 | whose value is a URI reference 151 | identifying itself. When used for this purpose, the "Link" header field 152 | MUST have a "rel" parameter whose value is "blocked-by". 153 | The intent is that the header be used to identify the entity actually 154 | implementing blockage, not any other entity mandating it. A 155 | human readable response body, as discussed above, is the appropriate 156 | location for discussion of administrative and policy issues. 157 |
158 | 159 |
160 | 161 | Clients cannot rely upon the use of the 451 status code. 162 | It is possible that certain legal authorities might wish 163 | to avoid transparency, and not only demand the restriction of access 164 | to certain resources, but also avoid disclosing that the demand 165 | was made. 166 | 167 |
168 | 169 |
170 | The HTTP Status Codes Registry should be updated with the 171 | following entry: 172 | 173 | 174 | Code: 451 175 | Description: Unavailable for Legal Reasons 176 | Specification: [ this document ] 177 | 178 | 179 | The Link Relation Type Registry should updated with the 180 | following entry: 181 | 182 | Relation Name: blocked-by 183 | Description: Identifies the entity blocking access to a resource 184 | folllowing on receipt of a legal demand. 185 | Reference: This document 186 | 187 |
188 | 189 | 190 | 191 | 192 | 193 | &rfc2119; 194 | &rfc7234; 195 | &rfc3986; 196 | &rfc5988; 197 | 198 | 199 | 200 | &rfc4084; 201 | &rfc4924; 202 | 203 | 204 |
205 | Thanks to Terence Eden, who observed that the existing 206 | status code 403 was not really suitable for this situation, and 207 | suggested the creation of a new status code. 208 | Thanks also to Ray Bradbury. 209 |
210 | 211 | 212 | 213 | 214 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-early-hints.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: An HTTP Status Code for Indicating Hints 3 | abbrev: Early Hints 4 | docname: draft-ietf-httpbis-early-hints-latest 5 | date: {DATE} 6 | category: exp 7 | 8 | ipr: trust200902 9 | area: General 10 | workgroup: HTTP 11 | keyword: Internet-Draft 12 | 13 | stand_alone: yes 14 | pi: [toc, tocindent, sortrefs, symrefs, strict, compact, comments, inline] 15 | 16 | author: 17 | - 18 | ins: K. Oku 19 | name: Kazuho Oku 20 | organization: Fastly 21 | email: kazuhooku@gmail.com 22 | 23 | normative: 24 | RFC2119: 25 | RFC7230: 26 | RFC7231: 27 | RFC7540: 28 | 29 | informative: 30 | Preload: 31 | title: Preload 32 | author: 33 | ins: I. Grigorik 34 | target: https://w3c.github.io/preload/ 35 | 36 | --- abstract 37 | 38 | This memo introduces an informational HTTP status code that can be used to convey hints that 39 | help a client make preparations for processing the final response. 40 | 41 | 42 | --- note_Note_to_Readers 43 | 44 | Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), 45 | which is archived at . 46 | 47 | Working Group information can be found at ; source code and issues list 48 | for this draft can be found at . 49 | 50 | 51 | --- middle 52 | 53 | # Introduction 54 | 55 | It is common for HTTP responses to contain links to external resources that need to be fetched 56 | prior to their use; for example, rendering HTML by a Web browser. Having such links available to 57 | the client as early as possible helps to minimize perceived latency. 58 | 59 | The "preload" ([Preload]) link relation can be used to convey such links in the Link header field 60 | of an HTTP response. However, it is not always possible for an origin server to generate the 61 | header block of a final response immediately after receiving a request. For example, the origin 62 | server might delegate a request to an upstream HTTP server running at a distant location, or the 63 | status code might depend on the result of a database query. 64 | 65 | The dilemma here is that even though it is preferable for an origin server to send some header fields as 66 | soon as it receives a request, it cannot do so until the status code and the full header fields of the 67 | final HTTP response are determined. 68 | 69 | HTTP/2 ([RFC7540]) server push can accelerate the delivery of resources, but only resources for which the server is authoritative. 70 | The other limitation of server push is that the response will be transmitted regardless of whether the client has the response cached. 71 | At the cost of spending one extra round-trip compared to server push in the worst case, delivering Link header fields in a timely fashion is more flexible and might consume less bandwidth. 72 | 73 | This memo defines a status code for sending an informational response ([RFC7231], Section 6.2) that 74 | contains header fields that are likely to be included in the final response. A server can send the 75 | informational response containing some of the header fields to help the client start making preparations 76 | for processing the final response, and then run time-consuming operations to generate the final 77 | response. The informational response can also be used by an origin server to trigger HTTP/2 server 78 | push at a caching intermediary. 79 | 80 | ## Notational Conventions 81 | 82 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 83 | "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in 84 | [RFC2119]. 85 | 86 | # 103 Early Hints 87 | 88 | The 103 (Early Hints) informational status code indicates to the client that the server is likely to 89 | send a final response with the header fields included in the informational response. 90 | 91 | Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final 92 | response as well. However, there might be cases when this is not desirable, such as when the server 93 | learns that they are not correct before the final response is sent. 94 | 95 | A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while 96 | waiting for the final response. For example, a client might recognize a Link header field value 97 | containing the relation type "preload" and start fetching the target resource. 98 | However, these header fields only provide hints to the client; they do not replace the header 99 | fields on the final response. 100 | 101 | Aside from performance optimizations, such evaluation of the 103 102 | (Early Hints) response's header fields MUST NOT affect how the final response is processed. A 103 | client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to 104 | the informational response itself (e.g., as metadata about the 103 (Early Hints) response). 105 | 106 | A server MAY use a 103 (Early Hints) response to indicate only some of the header fields that are expected to be found in the final response. 107 | A client SHOULD NOT interpret the nonexistence of a header field in a 103 (Early Hints) response as a speculation that the header field is unlikely to be part of the final response. 108 | 109 | The following example illustrates a typical message exchange that involves a 103 (Early Hints) response. 110 | 111 | Client request: 112 | 113 | ~~~ example 114 | GET / HTTP/1.1 115 | Host: example.com 116 | 117 | ~~~ 118 | 119 | Server response: 120 | 121 | ~~~ example 122 | HTTP/1.1 103 Early Hints 123 | Link: ; rel=preload; as=style 124 | Link: ; rel=preload; as=script 125 | 126 | HTTP/1.1 200 OK 127 | Date: Fri, 26 May 2017 10:02:11 GMT 128 | Content-Length: 1234 129 | Content-Type: text/html; charset=utf-8 130 | Link: ; rel=preload; as=style 131 | Link: ; rel=preload; as=script 132 | 133 | 134 | [... rest of the response body is omitted from the example ...] 135 | ~~~ 136 | 137 | As is the case with any informational response, a server might emit more than one 103 (Early Hints) 138 | response prior to sending a final response. 139 | This can happen for example when a caching intermediary generates a 103 (Early Hints) response based 140 | on the header fields of a stale-cached response, then forwards a 103 (Early Hints) response and a 141 | final response that were sent from the origin server in response to a revalidation request. 142 | 143 | A server MAY emit multiple 103 (Early Hints) responses with additional header fields as new information becomes available while the request is being processed. 144 | It does not need to repeat the fields that were already emitted, though it doesn't have to exclude them either. 145 | The client can consider any combination of header fields received in multiple 103 (Early Hints) responses when anticipating the list of header fields expected in the final response. 146 | 147 | The following example illustrates a series of responses that a server might emit. 148 | In the example, the server uses two 103 (Early Hints) responses to notify the client that it is likely to send three Link header fields in the final response. 149 | Two of the three expected header fields are found in the final response. 150 | The other header field is replaced by another Link header field that contains a different value. 151 | 152 | ~~~ example 153 | HTTP/1.1 103 Early Hints 154 | Link: ; rel=preload; as=style 155 | 156 | HTTP/1.1 103 Early Hints 157 | Link: ; rel=preload; as=style 158 | Link: ; rel=preload; as=script 159 | 160 | HTTP/1.1 200 OK 161 | Date: Fri, 26 May 2017 10:02:11 GMT 162 | Content-Length: 1234 163 | Content-Type: text/html; charset=utf-8 164 | Link: ; rel=preload; as=style 165 | Link: ; rel=preload; as=style 166 | Link: ; rel=preload; as=script 167 | 168 | 169 | [... rest of the response body is omitted from the example ...] 170 | ~~~ 171 | 172 | # Security Considerations 173 | 174 | Some clients might have issues handling 103 (Early Hints), since informational responses are rarely 175 | used in reply to requests not including an Expect header field ([RFC7231], Section 5.1.1). 176 | 177 | In particular, an HTTP/1.1 client that mishandles an informational response as a final response 178 | is likely to consider all responses to the succeeding requests sent over the same connection to be 179 | part of the final response. Such behavior might constitute a cross-origin information disclosure 180 | vulnerability in case the client multiplexes requests to different origins onto a single persistent 181 | connection. 182 | 183 | Therefore, a server might refrain from sending Early Hints over HTTP/1.1 unless the client is 184 | known to handle informational responses correctly. 185 | 186 | HTTP/2 clients are less likely to suffer from incorrect framing since handling of the response 187 | header fields does not affect how the end of the response body is determined. 188 | 189 | # IANA Considerations 190 | 191 | The HTTP Status Codes Registry will be updated with the following entry: 192 | 193 | * Code: 103 194 | * Description: Early Hints 195 | * Specification: \[this document] 196 | 197 | --- back 198 | 199 | # Changes 200 | 201 | ## Since draft-ietf-httpbis-early-hints-05 202 | 203 | * None yet. 204 | 205 | ## Since draft-ietf-httpbis-early-hints-04 206 | 207 | * Clarified that the server is allowed to add headers not found in a 103 response to the final response. 208 | * Clarify client's behavior when it receives more than one 103 response. 209 | 210 | ## Since draft-ietf-httpbis-early-hints-03 211 | 212 | * Removed statements that were either redundant or contradictory to RFC7230-7234. 213 | * Clarified what the server's expected behavior is. 214 | * Explain that a server might want to send more than one 103 response. 215 | * Editorial Changes. 216 | 217 | ## Since draft-ietf-httpbis-early-hints-02 218 | 219 | * Editorial changes. 220 | * Added an example. 221 | 222 | ## Since draft-ietf-httpbis-early-hints-01 223 | 224 | * Editorial changes. 225 | 226 | ## Since draft-ietf-httpbis-early-hints-00 227 | 228 | * Forbid processing the headers of a 103 response as part of the informational response. 229 | 230 | # Acknowledgements 231 | 232 | Thanks to Tatsuhiro Tsujikawa for coming up with the idea of sending the Link header fields using an 233 | informational response. 234 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-alias-proxy-status.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: HTTP Proxy-Status Parameter for Next-Hop Aliases 3 | abbrev: DNS Aliases Proxy-Status 4 | docname: draft-ietf-httpbis-alias-proxy-status-latest 5 | date: {DATE} 6 | category: std 7 | area: Applications and Real-Time 8 | workgroup: HTTP 9 | 10 | ipr: trust200902 11 | keyword: 12 | - proxy status 13 | 14 | stand_alone: yes 15 | pi: [toc, sortrefs, symrefs] 16 | 17 | venue: 18 | group: HTTP 19 | type: Working Group 20 | home: https://httpwg.org/ 21 | mail: ietf-http-wg@w3.org 22 | arch: https://lists.w3.org/Archives/Public/ietf-http-wg/ 23 | repo: https://github.com/httpwg/http-extensions/labels/alias-proxy-status 24 | github-issue-label: alias-proxy-status 25 | 26 | author: 27 | - 28 | ins: T. Pauly 29 | name: Tommy Pauly 30 | org: Apple, Inc. 31 | email: tpauly@apple.com 32 | 33 | informative: 34 | POSIX: 35 | title: "Standard for Information Technology Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7" 36 | author: 37 | org: IEEE 38 | target: http://ieeexplore.ieee.org/servlet/opac?punumber=6506089 39 | date: April 2013 40 | seriesinfo: 41 | DOI: 10.1109/ieeestd.2013.6506091 42 | 43 | --- abstract 44 | 45 | This document defines the `next-hop-aliases` HTTP Proxy-Status Parameter. This parameter carries 46 | the list of aliases and canonical names an intermediary received during DNS resolution as part 47 | of establishing a connection to the next hop. 48 | 49 | --- middle 50 | 51 | # Introduction 52 | 53 | The Proxy-Status HTTP response field {{!PROXY-STATUS=RFC9209}} allows intermediaries to convey 54 | information about how they handled the request in HTTP responses sent to clients. 55 | It defines a set of parameters that provide information, such as the name of the next 56 | hop. 57 | 58 | {{!PROXY-STATUS=RFC9209}} defines a `next-hop` parameter, which can contain a hostname, 59 | IP address, or alias of the next hop. This parameter can contain only one such item, 60 | so it cannot be used to communicate a chain of aliases encountered during DNS resolution 61 | when connecting to the next hop. 62 | 63 | Knowing the full chain of names that were used during DNS resolution via CNAME records 64 | {{!DNS=RFC1034}} is particularly useful for clients of forward proxies, in which the 65 | client is requesting to connect to a specific target hostname using the CONNECT method 66 | {{!HTTP=RFC9110}} or UDP proxying {{!CONNECT-UDP=RFC9298}}. CNAME records can be used to 67 | "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, 68 | and clients such as web browsers use the chain of DNS names to influence behavior like cookie 69 | usage policies {{?COOKIES=RFC6265}} or blocking of malicious hosts. 70 | 71 | This document allows clients to receive the CNAME chain of DNS names for the next hop 72 | by including the list of names in a new `next-hop-aliases` Proxy-Status parameter. 73 | 74 | ## Requirements 75 | 76 | {::boilerplate bcp14} 77 | 78 | # next-hop-aliases Parameter {#parameter} 79 | 80 | The `next-hop-aliases` parameter's value is a String {{!STRUCTURED-FIELDS=RFC8941}} that contains 81 | one or more DNS names in a comma-separated list. The items in the list include all alias names and 82 | canonical names received in CNAME records {{DNS}} during the course of resolving the next hop's 83 | hostname using DNS, and MAY include the original requested hostname itself. The names ought to 84 | appear in the order in which they were received in DNS, for the sake of consistency. If there 85 | are multiple CNAME records in the chain, the first name in the `next-hop-aliases` list would 86 | be the value in the CNAME record for the original hostname, and the final name in the 87 | `next-hop-aliases` list would be the name that ultimately resolved to one or more addresses. 88 | 89 | The list of DNS names in `next-hop-aliases` uses a comma (",") as a separator between names. 90 | Note that if a comma is included in a name itself, the comma must be encoded as described in 91 | {{encoding}}. 92 | 93 | For example, consider a proxy "proxy.example.net" that receives the following records when 94 | performing DNS resolution for the next hop "host.example.com": 95 | 96 | ~~~ dns-example 97 | host.example.com. CNAME tracker.example.com. 98 | tracker.example.com. CNAME service1.example.com. 99 | service1.example.com. AAAA 2001:db8::1 100 | ~~~ 101 | 102 | The proxy could include the following proxy status in its response: 103 | 104 | ~~~ http-message 105 | Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; 106 | next-hop-aliases="tracker.example.com,service1.example.com" 107 | ~~~ 108 | 109 | This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop 110 | for this request, encountered the names "tracker.example.com" and "service1.example.com" 111 | in the DNS resolution chain. Note that while this example includes both the `next-hop` and 112 | `next-hop-aliases` parameters, `next-hop-aliases` can be included without including `next-hop`. 113 | 114 | The proxy can also include the name of the next hop as the first item in the list. This is 115 | particularly useful for reverse proxies when clients would not otherwise know the name of the 116 | next hop, and the `next-hop` header is used to convey an IP address. 117 | 118 | For example, consider a proxy "reverseproxy.example.net" that receives the following records 119 | when performing DNS resolution for the next hop "host.example.com": 120 | 121 | ~~~ dns-example 122 | host2.example.com. CNAME service2.example.com. 123 | service2.example.com. AAAA 2001:db8::2 124 | ~~~ 125 | 126 | The proxy could include the following proxy status in its response: 127 | 128 | ~~~ http-message 129 | Proxy-Status: reverseproxy.example.net; next-hop="2001:db8::2"; 130 | next-hop-aliases="host2.example.com,service2.example.com" 131 | ~~~ 132 | 133 | The `next-hop-aliases` parameter only applies when DNS was used to resolve the next hop's name, and 134 | does not apply in all situations. Clients can use the information in this parameter to determine 135 | how to use the connection established through the proxy, but need to gracefully handle situations 136 | in which this parameter is not present. 137 | 138 | The proxy MAY send the empty string ("") as the value of `next-hop-aliases` to indicate that 139 | no CNAME records were encountered when resolving the next hop's name. 140 | 141 | ## Encoding special characters {#encoding} 142 | 143 | DNS names commonly just contain alphanumeric characters and hyphens ("-"), although they 144 | are allowed to contain any character ({{?RFC1035, Section 3.1}}), including a comma. To 145 | prevent commas or other special characters in names leading to incorrect parsing, 146 | any characters that appear in names in this list that do not belong to the set of URI 147 | Unreserved Characters ({{!RFC3986, Section 2.3}}) MUST be percent-encoded as 148 | defined in {{!RFC3986, Section 2.1}}. 149 | 150 | For example, consider the DNS name `comma,name.example.com`. This name would be encoded 151 | within a `next-hop-aliases` parameter as follows: 152 | 153 | ~~~ http-message 154 | Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; 155 | next-hop-aliases="comma%2Cname.example.com,service1.example.com" 156 | ~~~ 157 | 158 | It is also possible for a DNS name to include a period character (".") within a label, 159 | instead of as a label separator. In this case, the period character MUST be first escaped 160 | as "\\.". Since the "\\" character itself will be percent-encoded, the name 161 | "dot\\.label.example.com" would be encoded within a `next-hop-aliases` parameter as follows: 162 | 163 | ~~~ http-message 164 | Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; 165 | next-hop-aliases="dot%5C.label.example.com,service1.example.com" 166 | ~~~ 167 | 168 | Upon parsing this name, "dot%5C.label" MUST be treated as a single label. 169 | 170 | Similarly the "\\" character in a label MUST be escaped as "\\\\" and then percent-encoded. 171 | Other uses of "\\" MUST NOT appear in the label after percent-decoding. For example, 172 | if there is a DNS name "backslash\\name.example.com", it would first be escaped as 173 | "backslash\\\\name.example.com", and then percent-encoded as follows: 174 | 175 | ~~~ http-message 176 | Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; 177 | next-hop-aliases="backslash%5C%5Cname.example.com,service1.example.com" 178 | ~~~ 179 | 180 | # Implementation Considerations 181 | 182 | In order to include the `next-hop-aliases` parameter, a proxy needs to have access to the chain 183 | of alias names and canonical names received in CNAME records. 184 | 185 | Implementations ought to note that the full chain of names might not be available in common DNS 186 | resolution APIs, such as `getaddrinfo` {{POSIX}}. `getaddrinfo` does have an option for `AI_CANONNAME` 187 | ({{Section 6.1 of ?RFC3493}}), but this will only return the last name in the chain 188 | (the canonical name), not the alias names. 189 | 190 | An implementation MAY include incomplete information in the `next-hop-aliases` parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the implementation can only use `getaddrinfo` as described above. 191 | 192 | # Security Considerations {#sec-considerations} 193 | 194 | The `next-hop-aliases` parameter does not include any DNSSEC information or imply that DNSSEC was used. 195 | The information included in the parameter can only be trusted to be valid insofar as the client 196 | trusts the proxy to provide accurate information. This information is intended to be used as 197 | a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed 198 | through the proxy. 199 | 200 | Inspecting CNAME chains can be used to detect cloaking of trackers or malicious hosts. However, the 201 | CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking. 202 | In particular, recursive or authoritative resolvers can omit these records for both clients directly performing DNS name 203 | resolution and proxies performing DNS name resolution on behalf of client. A malicious proxy could 204 | also choose to not report these CNAME chains in order to hide the cloaking. In general, clients can 205 | trust information included (or not included) in the `next-hop-aliases` parameter to the degree 206 | that the proxy and any resolvers used by the proxy are trusted. 207 | 208 | # IANA Considerations 209 | 210 | This document registers the "next-hop-aliases" parameter 211 | in the "HTTP Proxy-Status Parameters" registry 212 | <[](https://www.iana.org/assignments/http-proxy-status)>. 213 | 214 | Name: 215 | : next-hop-aliases 216 | 217 | Description: 218 | : A string containing one or more DNS aliases or canonical names used to establish a 219 | proxied connection to the next hop. 220 | 221 | Reference: 222 | : This document 223 | -------------------------------------------------------------------------------- /draft-ietf-httpbis-incremental.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Incremental Forwarding of HTTP Messages" 3 | docname: draft-ietf-httpbis-incremental-latest 4 | category: std 5 | wg: httpbis 6 | ipr: trust200902 7 | keyword: internet-draft 8 | stand_alone: yes 9 | pi: [toc, sortrefs, symrefs] 10 | author: 11 | - 12 | fullname: 13 | :: 奥 一穂 14 | ascii: Kazuho Oku 15 | org: Fastly 16 | email: kazuhooku@gmail.com 17 | - 18 | fullname: Tommy Pauly 19 | organization: Apple 20 | email: tpauly@apple.com 21 | - 22 | fullname: Martin Thomson 23 | organization: Mozilla 24 | email: mt@lowentropy.net 25 | 26 | normative: 27 | EXTRA-STATUS: RFC6585 28 | PROXY-STATUS: RFC9209 29 | STRUCTURED-FIELDS: RFC9651 30 | 31 | informative: 32 | SSE: 33 | target: https://html.spec.whatwg.org/multipage/server-sent-events.html 34 | title: Server-Sent Events 35 | author: 36 | - 37 | org: WHATWG 38 | 39 | 40 | 41 | --- abstract 42 | 43 | This document specifies the "Incremental" HTTP header field, which instructs 44 | HTTP intermediaries to forward the HTTP message incrementally. 45 | 46 | 47 | --- middle 48 | 49 | # Introduction 50 | 51 | HTTP {{!HTTP=RFC9110}} permits receivers to begin processing portions of HTTP 52 | messages as they arrive, rather than requiring them to wait for the entire HTTP 53 | message to be received before acting. 54 | 55 | Some applications are specifically designed to take advantage of this 56 | capability. 57 | 58 | For example, Server-Sent Events {{SSE}} uses a long-running HTTP response, where 59 | the server continually sends notifications as they become available. 60 | 61 | In the case of Chunked Oblivious HTTP Messages 62 | {{?CHUNKED-OHTTP=I-D.ietf-ohai-chunked-ohttp}}, the client opens an HTTP request 63 | and incrementally sends application data, while the server can start responding 64 | even before the HTTP request is fully complete. In this way, the HTTP 65 | request-response pair could create what is, in effect, a bi-directional 66 | communication channel. 67 | 68 | Applications that rely on incremental delivery of data are fragile when HTTP intermediaries are involved. 69 | This is because HTTP intermediaries are not only permitted but are frequently 70 | deployed to buffer complete HTTP messages before forwarding them downstream 71 | ({{Section 7.6 of HTTP}}). 72 | 73 | If such a buffering HTTP intermediary exists between the client and the server, 74 | these applications may fail to function as intended. 75 | 76 | In the case of Server-Sent Events, an intermediary that tries to buffer the HTTP 77 | response completely before forwarding it could be left waiting indefinitely. 78 | A client might never receive any portion of the response. 79 | 80 | In the case of requests that involve any bi-directional exchange, 81 | an intermediary that tries to buffer entire messages -- 82 | either request or response -- prevents any data from being delivered. 83 | 84 | To help avoid such behavior, this document specifies the "Incremental" HTTP header 85 | field, which requests that HTTP intermediaries begin forwarding the HTTP message 86 | downstream before receiving the complete message. 87 | 88 | This indication is advisory. 89 | Intermediaries that are unaware of this field will not change their behavior. 90 | intermediaries that support the field might choose instead to reject a request; 91 | see {{security}}. 92 | 93 | 94 | # Conventions and Definitions 95 | 96 | {::boilerplate bcp14-tagged} 97 | 98 | This document relies on structured field definitions 99 | of Item and Boolean {{STRUCTURED-FIELDS}}. 100 | 101 | 102 | # The Incremental Header Field 103 | 104 | The Incremental HTTP header field expresses the sender's intent for HTTP 105 | intermediaries to start forwarding the message downstream before the entire 106 | message is received. 107 | 108 | The Incremental header field is defined as a structured field 109 | {{STRUCTURED-FIELDS}} of type Item. 110 | Only Boolean values ({{Section 3.3.6 of STRUCTURED-FIELDS}}) are valid; 111 | a recipient ignores the field if it contains any other type. 112 | 113 | ~~~ 114 | Incremental: ?1 115 | ~~~ 116 | 117 | A true value ("?1") indicates that the sender requests intermediaries to forward 118 | the message incrementally, as described below. 119 | 120 | ~~~ 121 | Incremental: ?0 122 | ~~~ 123 | 124 | A false value ("?0") indicates the default behavior defined in {{HTTP}}, where 125 | intermediaries might buffer the entire message before forwarding it. However, 126 | this explicit signal might increase intermediaries' confidence in doing so. 127 | 128 | The Incremental HTTP header field applies to each HTTP message. Therefore, if 129 | both the HTTP request and response need to be forwarded incrementally, the 130 | Incremental HTTP header field MUST be set for both the HTTP request and the 131 | response. 132 | 133 | Upon receiving a header section that includes an Incremental header field with a 134 | true value, HTTP intermediaries SHOULD NOT buffer the entire message before 135 | forwarding it. Instead, intermediaries SHOULD transmit the header section 136 | downstream and continuously forward the bytes of the message content as they 137 | arrive. As the Incremental header field indicates only how the message content is 138 | to be forwarded, intermediaries can still buffer the entire header and trailer 139 | sections of the message before forwarding them downstream. 140 | 141 | If an intermediary decides outright to refuse forwarding the message body 142 | incrementally, the intermediary MUST generate an error response rather than 143 | buffering an entire message before forwarding. Typical scenarios under which an 144 | intermediary might refuse are discussed in {{security}}. 145 | 146 | The request to use incremental forwarding also applies to HTTP implementations. 147 | Though most HTTP APIs provide the ability to incrementally transfer message content, 148 | those that do not for any reason, SHOULD use the presence of the Incremental 149 | header field to reduce or disable buffering. 150 | 151 | The Incremental field is advisory, as intermediaries that are unaware of the 152 | field or that do not support the field might buffer messages, even when 153 | explicitly requested otherwise. Clients and servers therefore cannot expect all 154 | intermediaries to understand and respect a request to deliver messages 155 | incrementally. Clients can rely on prior knowledge or probe for support on 156 | individual resources. 157 | 158 | The Incremental header field facilitates the establishment of a bidirectional 159 | byte channel over HTTP, as its presence in both requests and responses requests that 160 | intermediaries forward early responses ({{Section 7.5 of HTTP}}) and to 161 | transmit message contents incrementally in both directions. However, when developing 162 | bidirectional protocols over HTTP, Extended CONNECT {{?RFC8441}}{{?RFC9220}} is 163 | generally more consistent with HTTP's architecture. 164 | 165 | This document does not define any parameters for the Incremental header field 166 | value, but future documents might define parameters. Receivers MUST ignore 167 | unknown parameters. 168 | 169 | 170 | # Security Considerations {#security} 171 | 172 | When receiving a request or response that asks for incremental forwarding, 173 | intermediaries might reject the HTTP request due to security concerns. 174 | The following subsections explore typical scenarios 175 | under which the intermediaries might reject requests. 176 | 177 | Note that rejecting requests based on the value of the Incremental field 178 | only occurs when an intermediary understands the field. 179 | 180 | 181 | ## Permanent Rejection 182 | 183 | Some intermediaries inspect the content of HTTP messages and forward them only 184 | if their content is deemed safe. Any feature that depends on seeing the 185 | entirety of the message in this way is incompatible with incremental delivery. 186 | 187 | When an intermediary is asked to incrementally forward message and cannot -- 188 | whether that message is a request or a response -- 189 | due to security concerns about the message content, 190 | the intermediary SHOULD respond with a 501 (Not Implemented) error 191 | with an incremental_refused Proxy-Status response header field 192 | ({{iana-considerations}}). 193 | 194 | 195 | ## Temporary Rejection 196 | 197 | To conserve resources required to handle HTTP requests or connections, it is 198 | common for intermediaries to impose limits on the maximum number of concurrent 199 | HTTP requests that they forward, while buffering requests that exceed this 200 | limit. 201 | 202 | Such intermediaries could apply a more restrictive concurrency limit to requests 203 | marked as incremental to ensure that capacity remains available for 204 | non-incremental requests, even when the maximum number of incremental requests 205 | is reached. This approach helps balance the processing of different types of 206 | requests and maintains service availability across all requests. 207 | 208 | When rejecting incremental requests due to reaching the concurrency limit, 209 | intermediaries SHOULD respond with a 429 (Too Many Requests) error 210 | ({{Section 4 of EXTRA-STATUS}}), 211 | accompanied by a connection_limit_reached Proxy-Status response header field 212 | ({{Section 2.3.12 of PROXY-STATUS}}). 213 | 214 | 215 | ## Handling of Small Packets 216 | 217 | For performance and efficiency reasons, a small amount of buffering might be 218 | used by intermediaries, even for incremental messages. Immediate forwarding 219 | might be exploited to cause an intermediary to waste effort on many small 220 | packets. Enabling incremental delivery might instead set limits on the number 221 | bytes that are buffered or the time that buffers are held before forwarding. 222 | Any buffering could adversely affect application latency, even if it improves 223 | efficiency. In all cases, intermediaries cannot hold data in buffers 224 | indefinitely, so data needs to be forwarded when either the time limit or the 225 | byte limit is reached. 226 | 227 | 228 | # IANA Considerations 229 | 230 | An HTTP field named Incremental is registered 231 | in the Hypertext Transfer Protocol (HTTP) Field Name Registry, 232 | following the procedures in {{Section 18.4 of !HTTP=RFC9110}}. 233 | The following values are registered: 234 | 235 | Field Name: 236 | : Incremental 237 | 238 | Status: 239 | : permanent 240 | 241 | Structured Type: 242 | : Item 243 | 244 | Reference: 245 | : This document 246 | 247 | Comments: 248 | : None 249 | {:compact} 250 | 251 | An HTTP Proxy Error Type is registered in the HTTP Proxy Error Types registry as 252 | shown below: 253 | 254 | Name: 255 | : incremental_refused 256 | 257 | Description: 258 | : The HTTP message contained the Incremental HTTP header field, but the 259 | intermediary refused to forward the message incrementally. 260 | 261 | Extra Parameters: 262 | : none 263 | 264 | Recommended HTTP Status Code: 265 | : 501 266 | 267 | Response Only Generated By Intermediaries: 268 | : true 269 | 270 | Reference: 271 | : This document 272 | {:compact} 273 | 274 | --- back 275 | 276 | # Acknowledgments 277 | {:numbered="false"} 278 | 279 | The authors would like to thank many members of the IETF HTTP working group for 280 | their discussions and feedback on this specification. In particular, the authors 281 | would like to thank {{{Mark Thomas}}}, {{{Piotr Sikora}}}, 282 | {{{Thibault Meunier}}}, {{{Marius Kleidl}}}, {{{Ben Schwartz}}}, 283 | {{{Willy Tarreau}}}, {{{Will Hawkins}}}, {{{Mark Nottingham}}}, and 284 | {{{Lucas Pardue}}} for close review and sugggested changes. 285 | -------------------------------------------------------------------------------- /archive/draft-ietf-httpbis-h2-websockets.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Bootstrapping WebSockets with HTTP/2 3 | abbrev: H2 Websockets 4 | docname: draft-ietf-httpbis-h2-websockets-latest 5 | date: {DATE} 6 | category: std 7 | updates: 6455 8 | area: Applications and Real-Time 9 | workgroup: HTTP 10 | keyword: Internet-Draft 11 | 12 | ipr: trust200902 13 | stand_alone: yes 14 | pi: [toc, tocindent, sortrefs, symrefs, strict, compact, comments, inline] 15 | 16 | author: 17 | - 18 | ins: P. McManus 19 | name: Patrick McManus 20 | organization: Mozilla 21 | email: mcmanus@ducksong.com 22 | 23 | normative: 24 | 25 | --- abstract 26 | 27 | This document defines a mechanism for running the WebSocket Protocol (RFC 6455) 28 | over a single stream of an HTTP/2 connection. 29 | 30 | --- middle 31 | 32 | # Introduction 33 | 34 | The Hypertext Transfer Protocol (HTTP) {{!RFC7230}} provides compatible resource-level semantics 35 | across different versions but it does not offer compatibility at the connection management 36 | level. Other protocols, such as WebSockets, that rely on connection management details of HTTP must 37 | be updated for new versions of HTTP. 38 | 39 | The WebSocket Protocol {{!RFC6455}} uses the HTTP/1.1 40 | Upgrade mechanism (Section 6.7 of {{!RFC7230}}) to transition a TCP connection from HTTP into a 41 | WebSocket connection. A different approach must be taken with HTTP/2 42 | {{!RFC7540}}. HTTP/2 does not allow connection-wide header fields and status 43 | codes such as the Upgrade and Connection request header fields or the 101 44 | (Switching Protocols) response code due to its multiplexing nature. These are all required 45 | by the {{!RFC6455}} opening handshake. 46 | 47 | Being able to bootstrap WebSockets from HTTP/2 allows one TCP 48 | connection to be shared by both protocols and extends HTTP/2's 49 | more efficient use of the network to WebSockets. 50 | 51 | This document extends the HTTP CONNECT method (as specified for HTTP/2 in Section 8.3 of 52 | {{RFC7540}}). The extension allows the substitution of a new protocol name to connect to rather than 53 | the external host normally used by CONNECT. The result is a tunnel on a single HTTP/2 stream that 54 | can carry data for WebSockets (or any other protocol). The other streams on the connection may carry 55 | more extended CONNECT tunnels, traditional HTTP/2 data, or a mixture of both. 56 | 57 | This tunneled stream will be multiplexed with other regular streams on 58 | the connection and enjoys the normal priority, cancellation, and flow 59 | control features of HTTP/2. 60 | 61 | Streams that successfully establish a WebSocket connection using a 62 | tunneled stream and the modifications to the opening handshake defined 63 | in this document then use the traditional WebSocket Protocol, treating 64 | the stream as if were the TCP connection in that specification. 65 | 66 | # Terminology 67 | 68 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 70 | and "OPTIONAL" in this document are to be interpreted as described in 71 | BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they 72 | appear in all capitals, as shown here. 73 | 74 | # The SETTINGS_ENABLE_CONNECT_PROTOCOL SETTINGS Parameter 75 | 76 | This document adds a new SETTINGS Parameter to those defined by 77 | {{!RFC7540}}, Section 6.5.2. 78 | 79 | The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL. The value 80 | of the parameter MUST be 0 or 1. 81 | 82 | Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1, a client 83 | MAY use the Extended CONNECT definition of this document when creating new 84 | streams. Receipt of this parameter by a server does not have any 85 | impact. 86 | 87 | A sender MUST NOT send a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the 88 | value of 0 after previously sending a value of 1. 89 | 90 | The use of a SETTINGS Parameter to opt-in to an otherwise incompatible 91 | protocol change is a use of "Extending HTTP/2" defined by Section 5.5 92 | of {{!RFC7540}}. Specifically, the addition a new pseudo-header field ":protocol" and the change in meaning 93 | of the ":authority" pseudo-header field in {{method}} require opt-in negotiation. If a client were to use the provisions of the extended 94 | CONNECT method defined in this document without first receiving a 95 | SETTINGS_ENABLE_CONNECT_PROTOCOL parameter, a non-supporting peer would 96 | detect a malformed request and generate a stream error (Section 97 | 8.1.2.6 of {{!RFC7540}}). 98 | 99 | # The Extended CONNECT Method {#method} 100 | 101 | Usage of the CONNECT method in HTTP/2 is defined by Section 8.3 of 102 | {{!RFC7540}}. This extension modifies the method in the following ways: 103 | 104 | * A new pseudo-header field :protocol MAY be included on request HEADERS indicating the desired protocol 105 | to be spoken on the tunnel created by CONNECT. The pseudo-header field is single valued and contains a 106 | value from the HTTP Upgrade Token Registry located at 107 | https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml 108 | 109 | * On requests that contain the :protocol pseudo-header field, the :scheme and 110 | :path pseudo-header fields of the target URI (See {{usingExtended}}) MUST also be included. 111 | 112 | * On requests bearing the :protocol pseudo-header field, the :authority 113 | pseudo-header field is interpreted according to Section 8.1.2.3 114 | of {{!RFC7540}} instead of Section 8.3 of {{!RFC7540}}. In particular, the server 115 | MUST NOT create a tunnel to the host indicated by the :authority as it 116 | would with a CONNECT method request that was not modified by this extension. 117 | 118 | Upon receiving a CONNECT request bearing the :protocol pseudo-header field 119 | the server establishes a tunnel to another service of the protocol 120 | type indicated by the pseudo-header field. This service may or may not be 121 | co-located with the server. 122 | 123 | # Using Extended CONNECT To Bootstrap the WebSocket Protocol {#usingExtended} 124 | 125 | The :protocol pseudo-header field MUST be included in the CONNECT request 126 | and it MUST have a value of `websocket` to initiate a WebSocket 127 | connection on an HTTP/2 stream. Other HTTP request and response 128 | header fields, such as those for manipulating cookies, may be included in 129 | the HEADERS with the CONNECT method as usual. This request replaces 130 | the GET-based request in {{!RFC6455}} and is used to process the 131 | WebSockets opening handshake. 132 | 133 | The scheme of the target URI (Section 5.1 of {{!RFC7230}}) MUST be `https` for `wss` schemed 134 | WebSockets and `http` for `ws` schemed WebSockets. The remainder of the Target URI is the same as 135 | the websocket URI. The websocket URI is still used for proxy autoconfiguration. The security 136 | requirements for the HTTP/2 connection used by this specification are established by {{!RFC7540}} 137 | for https requests and {{!RFC8164}} for http requests. 138 | 139 | {{!RFC6455}} requires the use of Connection and Upgrade header fields that 140 | are not part of HTTP/2. They MUST NOT be included in the CONNECT 141 | request defined here. 142 | 143 | {{!RFC6455}} requires the use of a Host header field which is also not part of 144 | HTTP/2. The Host information is conveyed as part of the :authority 145 | pseudo-header field which is required on every HTTP/2 transaction. 146 | 147 | Implementations using this extended CONNECT to bootstrap WebSockets do 148 | not do the processing of the {{!RFC6455}} Sec-WebSocket-Key and 149 | Sec-WebSocket-Accept header fields as that functionality has been superseded 150 | by the :protocol pseudo-header field. 151 | 152 | The Origin {{!RFC6454}}, Sec-WebSocket-Version, Sec-WebSocket-Protocol, 153 | and Sec-WebSocket-Extensions header fields are used in the CONNECT request 154 | and response header fields in the same way as defined in {{!RFC6455}}. Note 155 | that HTTP/1 header field names were case-insensitive and HTTP/2 requires 156 | they be encoded as lower case. 157 | 158 | After successfully processing the opening handshake, the peers should 159 | proceed with the WebSocket Protocol {{!RFC6455}} using the HTTP/2 160 | stream from the CONNECT transaction as if it were the TCP connection 161 | referred to in {{!RFC6455}}. The state of the WebSocket connection at 162 | this point is OPEN as defined by {{!RFC6455}}, Section 4.1. 163 | 164 | The HTTP/2 stream closure is also analogous to the TCP connection closure of 165 | {{!RFC6455}}. Orderly TCP level closures are represented as END_STREAM 166 | ({{!RFC7540}}, Section 6.1) flags and RST exceptions are represented 167 | with the RST_STREAM ({{!RFC7540}}, Section 6.4) frame with the CANCEL 168 | ({{!RFC7540}}, Section 7) error code. 169 | 170 | ## Example 171 | ~~~ example 172 | [[ From Client ]] [[ From Server ]] 173 | 174 | SETTINGS 175 | SETTINGS_ENABLE_CONNECT_[..] = 1 176 | 177 | HEADERS + END_HEADERS 178 | :method = CONNECT 179 | :protocol = websocket 180 | :scheme = https 181 | :path = /chat 182 | :authority = server.example.com 183 | sec-websocket-protocol = chat, superchat 184 | sec-websocket-extensions = permessage-deflate 185 | sec-websocket-version = 13 186 | origin = http://www.example.com 187 | 188 | HEADERS + END_HEADERS 189 | :status = 200 190 | sec-websocket-protocol = chat 191 | 192 | DATA 193 | WebSocket Data 194 | 195 | DATA + END_STREAM 196 | WebSocket Data 197 | 198 | DATA + END_STREAM 199 | WebSocket Data 200 | ~~~ 201 | 202 | # Design Considerations 203 | 204 | A more native integration with HTTP/2 is certainly possible with 205 | larger additions to HTTP/2. This design was selected to minimize the 206 | solution complexity while still addressing the primary concern of running 207 | HTTP/2 and WebSockets concurrently. 208 | 209 | # About Intermediaries 210 | 211 | This document does not change how WebSockets interacts with HTTP forward 212 | proxies. If a client wishing to speak WebSockets connects via HTTP/2 213 | to an HTTP proxy it should continue to use a traditional (i.e. not with 214 | a :protocol pseudo-header field) CONNECT to tunnel through that proxy to the 215 | WebSocket server via HTTP. 216 | 217 | The resulting version of HTTP on that tunnel determines whether 218 | WebSockets is initiated directly or via a modified CONNECT request 219 | described in this document. 220 | 221 | # Security Considerations 222 | 223 | {{!RFC6455}} ensures that non-WebSockets clients, especially 224 | XMLHttpRequest based clients, cannot make a WebSocket connection. Its 225 | primary mechanism for doing that is the use of Sec- prefixed request 226 | header fields that cannot be created by XMLHttpRequest-based clients. This 227 | specification addresses that concern in two ways: 228 | 229 | * XMLHttpRequest also prohibits use of the CONNECT method in addition to Sec- prefixed request 230 | header fields. 231 | 232 | * The use of a pseudo-header field is something that is connection specific 233 | and HTTP/2 does not ever allow to be created outside of the protocol stack. 234 | 235 | The security considerations of {{!RFC6455}} section 10 continue to apply to the use of the WebSocket 236 | Protocol when using this specification with the exception of 10.8. That section is not relevant 237 | because it is specific to the boostrapping handshake that is changed in this document. 238 | 239 | # IANA Considerations 240 | 241 | This document establishes an entry for the HTTP/2 Settings Registry 242 | that was established by Section 11.3 of {{!RFC7540}}. 243 | 244 | Name: SETTINGS_ENABLE_CONNECT_PROTOCOL 245 | 246 | Code: 0x8 247 | 248 | Initial Value: 0 249 | 250 | Specification: This document 251 | 252 | --- back 253 | 254 | # Acknowledgments 255 | {:numbered="false"} 256 | The 2017 HTTP Workshop had a very productive discussion that helped 257 | determine the key problem and acceptable level of solution complexity. 258 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contributing to HTTP 3 | description: How to participate in the HTTP Working Group 4 | --- 5 | 6 | Anyone can contribute to HTTP; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work, as outlined below, is part of the HTTP Working Group. 7 | 8 | Before doing so, it's a good idea to familiarize yourself with our [charter](https://datatracker.ietf.org/wg/httpbis/about/), and [home page](https://httpwg.org/). If you're new to the [IETF](https://www.ietf.org/), you may also want to read [an informal guide to the IETF process](https://www.ietf.org/standards/process/informal/) and the [Tao of the IETF](https://www.ietf.org/tao.html). 9 | 10 | **Be aware that all contributions fall under the "NOTE WELL" terms outlined below.** 11 | 12 | 13 | 14 | 15 | 16 | - [Contributing to Work in Progress](#contributing-to-work-in-progress) 17 | - [Following Discussion](#following-discussion) 18 | - [Raising Issues](#raising-issues) 19 | - [Resolving Issues](#resolving-issues) 20 | - [Pull Requests](#pull-requests) 21 | - [Proposing New Work](#proposing-new-work) 22 | - [Other Venues for HTTP Work](#other-venues-for-http-work) 23 | - [Bringing Work to the IETF](#bringing-work-to-the-ietf) 24 | - [Code of Conduct](#code-of-conduct) 25 | - [NOTE WELL](#note-well) 26 | 27 | 28 | 29 | 30 | ## Contributing to Work in Progress 31 | 32 | ### Following Discussion 33 | 34 | The HTTP Working Group has a few venues for discussion: 35 | 36 | * We have a session at most [IETF meetings](https://www.ietf.org/meeting/), and sometimes in between (called an "interim" meeting). See our [meeting materials repository](https://httpwg.org/wg-materials), and the [official IETF proceedings](https://datatracker.ietf.org/wg/httpbis/meetings/) for details. 37 | 38 | * Our [mailing list](https://lists.w3.org/Archives/Public/ietf-http-wg/) ([subscribe](mailto:ietf-http-wg-request@w3.org?subject=subscribe)) is used for notifications of meetings, adoption of documents, consensus calls, issue discussion, and other business. It's not mandatory to subscribe, but you're likely to miss important things if you don't; also, note that e-mail sent to this list will be manually moderated (and thus delayed) if you are not subscribed. 39 | 40 | * We discuss most document issues on [GitHub](https://github.com/httpwg/). 41 | 42 | You can participate in any or all of these places. 43 | 44 | 45 | ### Raising Issues 46 | 47 | We use GitHub to track discussion items and their resolution. Before filing a new issue, please consider a few things: 48 | 49 | * Issues should be just that: issues with our deliverables, **not proposals for new work, questions, or support requests**. 50 | 51 | * There may be an existing duplicate issue, so please review the issues list first. 52 | 53 | * If you're not sure how to phrase your issue, please ask on the [mailing list](#following-discussion). 54 | 55 | Issues can also be raised on the [mailing list](#following-discussion) by clearly marking them as such (e.g., with `New issue` in the `Subject:` line). 56 | 57 | Be aware that issues might be rephrased, changed in scope, or combined with others. If you feel that an important part of your original issue has been lost, please bring it up (on the issue or on the list). 58 | 59 | Off-topic and duplicate issues will be closed without discussion. Note that commit comments will only be responded to with best effort, and may not be seen. 60 | 61 | 62 | ### Resolving Issues 63 | 64 | As in all IETF Working Groups, final consensus of the Working Group is determined during Working Group Last Call; consensus established during issue discussion provides a limited precedent, to prevent revisiting topics unnecessarily. Our issues list provides a mechanism for tracking those discussions and their outcomes. 65 | 66 | Some issues might be labeled as `editorial`; they can be dealt with by the editor(s) without consensus or notification, and discussion will take place on the issue itself. If you believe an `editorial` issue is not purely editorial, please say so on the issue; the Chair(s) will make a determination. 67 | 68 | The remaining `open` issues in the issues list are those that need Working Group discussion. 69 | 70 | Issues can be discussed on the mailing list or the issues list. The editors can also propose resolutions to issues for the group's consideration by incorporating them into the draft(s). 71 | 72 | When an issue is `closed`, it implies that the issue's proposed resolution is reflected in the draft(s). When a new draft is published, the issues that have been closed since the last draft will be highlighted in the draft's change notes and/or on the mailing list, to aid reviewers. 73 | 74 | Note that whether or not an issue is closed does not necessarily reflect consensus of the Working Group; an issue's `open`/`closed` state is only used to organise our discussions. If you have a question or problem with an issue in the `closed` state, please say so (either on the issue or the mailing list). 75 | 76 | Some issues might require an explicit consensus call; if consensus is achieved in this manner, the issue will be labeled with `has-consensus`. Reopening issues with `has-consensus` requires new information (in the judgement of the Chairs). 77 | 78 | 79 | ### Pull Requests 80 | 81 | We welcome pull requests, both for editorial suggestions and to resolve open issues. In the latter case, please identify the relevant issue. 82 | 83 | Please do not use a pull request to open a new issue. Instead, file an issue and refer to it from the pull request. 84 | 85 | 86 | ## Proposing New Work 87 | 88 | If you'd like to propose a new HTTP extension (e.g., method, header, status code, HTTP/2 or HTTP/3 SETTINGS), it's best to first describe your use case on the [mailing list](#following-discussion). Often, there's an existing HTTP feature that can be used. 89 | 90 | If a new extension is necessary, we usually discuss them in Internet-Draft form. However, if you're unfamiliar with that format, write down your proposal precisely but succinctly and send it to the [mailing list](#following-discussion). 91 | 92 | If there is interest in the proposal, the Chairs will issue a _Call for Adoption_, where Working Group participants comment on whether or not they support adoption, and whether or not they might implement it. 93 | 94 | Upcoming proposals and calls for adoption are tracked by the Chairs in the [admin repository](https://github.com/httpwg/admin/labels/adoption). 95 | 96 | If the Chairs determine that there is consensus to adopt the document, the Working Group will start discussing it. 97 | 98 | Once a draft is adopted, the Chairs will assign one or more editors to the document. Although this will sometimes be the same person(s) that made the original proposal, it might not be, for various reasons; it could be that an experienced editor is needed for a tricky draft, or your contribution as a participant, rather than a neutral editor, is judged more valuable. In any case, the Chairs will discuss editor selection with you before making an announcement. 99 | 100 | The Editor(s) first task will be to upload an initial draft into a Working Group repository. If you're selected as an editor, the Chairs will be in touch with more details. 101 | 102 | ### Other Venues for HTTP Work 103 | 104 | There are other places inside and outside the IETF that are doing HTTP-related work. Depending on the nature of your proposal, you might consider taking your work to one of the following venues: 105 | 106 | * The [HTTP APIs Working Group](https://datatracker.ietf.org/wg/httpapi/about/) focuses on API-related HTTP extensions and similar specifications 107 | * The [DISPATCH Working Group](https://datatracker.ietf.org/wg/dispatch/about/) decides where it's most appropriate to take new work in the IETF's Applications and RealTime (ART) area. While you can come directly to the HTTP Working Group with a proposal, you can also take it there. Sometimes that can lead to starting a new Working Group (often for larger or more specialised work) 108 | * The [WHATWG Fetch Specification](https://fetch.spec.whatwg.org/) defines the API for HTTP that browsers expose 109 | 110 | ### Bringing Work to the IETF 111 | 112 | There are a few things that are important to know when you bring work to the IETF. 113 | 114 | First, when your draft is adopted by the Working Group _change control_ -- that is, who determines what's in the specification -- passes from you to the IETF. That means that some things that you don't agree with might happen to it, and it might be published with things that you wouldn't have included (or without things that you would have kept). 115 | 116 | That's because the document's content is determined by consensus of the Working Group, and then the IETF overall. Even though you started it, the document needs to reflect the community's input, and that takes primacy. 117 | 118 | As a result, whenever a document is adopted it's considered a _starting point_ -- i.e., nothing is "locked down". Of course, you will have ample opportunity to discuss any issues you have with proposed changes, and if you make a convincing argument, consensus should follow. However, it's important that you are able to accept that the document will change. If you just want it rubber-stamped, it's not appropriate to bring it to the IETF. 119 | 120 | Why should you bring your document here, if you have to give up control? Not only will your work benefit from the broad review from many HTTP implementers and practitioners, but that community will also be more likely to implement and use an extension once it has gone through that process. 121 | 122 | 123 | ## Code of Conduct 124 | 125 | The [IETF Guidelines for Conduct](https://www.rfc-editor.org/rfc/rfc7154.html) applies to all Working Group communications and meetings. 126 | 127 | 128 | ## NOTE WELL 129 | 130 | By participating in the IETF you agree to follow [IETF processes and policies](https://www.ietf.org/policies/). This Note Well is a reminder of some of those policies. 131 | 132 | * IETF participants are expected to behave in a professional manner and extend respect and courtesy to their colleagues at all times (see [RFC 7154: IETF Guidelines for Conduct](https://www.rfc-editor.org/rfc/rfc7154.html) and [IETF Anti-Harassment Policy](https://datatracker.ietf.org/doc/statement-iesg-ietf-anti-harassment-policy-20131103/)). If you have any concerns about behavior, please contact the [Ombudsteam](https://www.ietf.org/contact/ombudsteam/) who have a duty of confidentiality and extensive powers to act, as set out in [RFC 7776: IETF Anti-Harassment Procedures](https://www.rfc-editor.org/rfc/rfc7776.html). 133 | 134 | * If you are aware that any IETF contribution (as defined in [RFC 5378: Rights Contributors Provide to the IETF Trust](https://www.rfc-editor.org/rfc/rfc5378.html)) is covered by patents or patent applications that are owned or controlled by you, your employer or your sponsor, you must disclose that fact, or not participate in the discussion (see [RFC 8179: Intellectual Property Rights in IETF Technology](https://www.rfc-editor.org/rfc/rfc8179.html)). 135 | 136 | * For detailed process information consult [RFC 2026: Internet Standards Process](https://www.rfc-editor.org/rfc/rfc2026.html) and [RFC 2418: IETF Working Group Guidelines and Procedures](https://www.rfc-editor.org/rfc/rfc2418.html) and updates to those. 137 | 138 | * The IETF routinely makes public written, audio, video, and photographic records of IETF activities, including your personal information as set out in the [IETF Privacy Statement](https://www.ietf.org/privacy-statement/). 139 | 140 | For advice, please talk to Working Group chairs or Area Directors. 141 | 142 | ## Working Group Information 143 | 144 | Discussion of this work occurs on the [HTTP 145 | Working Group mailing list](mailto:ietf-http-wg@w3.org) 146 | ([archive](http://lists.w3.org/Archives/Public/ietf-http-wg/), 147 | [subscribe](ietf-http-wg-request@w3.org)). 148 | In addition to contributions in GitHub, you are encouraged to participate in 149 | discussions there. 150 | 151 | **Note**: Some working groups adopt a policy whereby substantive discussion of 152 | technical issues needs to occur on the mailing list. 153 | 154 | You might also like to familiarize yourself with other 155 | [Working Group documents](https://datatracker.ietf.org/wg/httpbis/documents/). 156 | --------------------------------------------------------------------------------