draft-ietf-httpbis-optimistic-upgrade-01.txt   draft-ietf-httpbis-optimistic-upgrade-latest.txt 
HTTPBIS Working Group HTTPBIS Working Group
Internet-Draft Meta Platforms, Inc. Internet-Draft Meta Platforms, Inc.
Updates: 9298 (if approved) October 21, 2024 Updates: 9298 (if approved) December 18, 2024
Intended status: Standards Track Intended status: Standards Track
Expires: April 24, 2025 Expires: June 21, 2025
Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
draft-ietf-httpbis-optimistic-upgrade-01 draft-ietf-httpbis-optimistic-upgrade-latest
Abstract Abstract
In HTTP/1.1, the client can request a change to a new protocol on the In HTTP/1.1, the client can request a change to a new protocol on the
existing connection. This document discusses the security existing connection. This document discusses the security
considerations that apply to data sent by the client before this considerations that apply to data sent by the client before this
request is confirmed, and updates RFC 9298 to avoid related security request is confirmed, and updates RFC 9298 to avoid related security
issues. issues.
About This Document About This Document
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2025. This Internet-Draft will expire on June 21, 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 48 skipping to change at page 8, line 48
Tokens are specified only for use with the "GET" method. Tokens are specified only for use with the "GET" method.
Future specifications for Upgrade Tokens should restrict their use to Future specifications for Upgrade Tokens should restrict their use to
"GET" requests if the HTTP method is otherwise irrelevant and a "GET" requests if the HTTP method is otherwise irrelevant and a
request body is not required. This improves consistency with other request body is not required. This improves consistency with other
Upgrade Tokens and reduces the likelihood that a faulty server Upgrade Tokens and reduces the likelihood that a faulty server
implementation might process the request body as the new protocol. implementation might process the request body as the new protocol.
7. Guidance for HTTP CONNECT 7. Guidance for HTTP CONNECT
Clients that send HTTP CONNECT requests on behalf of untrusted TCP In HTTP/1.1, clients that send CONNECT requests on behalf of
clients MUST wait for a 2xx (Successful) response before sending any untrusted TCP clients MUST wait for a 2xx (Successful) response
TCP payload data. before sending any TCP payload data.
To mitigate vulnerabilities from any clients that do not conform to To mitigate vulnerabilities from any clients that do not conform to
this requirement, proxy servers MAY close the underlying connection this requirement, proxy servers MAY close the underlying connection
when rejecting an HTTP CONNECT request, without processing any when rejecting an HTTP/1.1 CONNECT request, without processing any
further data sent to the proxy server on that connection. Note that further data sent to the proxy server on that connection. Note that
this behavior may impair performance, especially when returning a this behavior may impair performance, especially when returning a
"407 (Proxy Authentication Required)" response. "407 (Proxy Authentication Required)" response.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. References 9. References
 End of changes. 6 change blocks. 
8 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/