draft-ietf-httpbis-alias-proxy-status-05.txt | draft-ietf-httpbis-alias-proxy-status-latest.txt | |||
---|---|---|---|---|
HTTP Working Group T. Pauly | HTTP Working Group T. Pauly | |||
Internet-Draft Apple, Inc. | Internet-Draft Apple, Inc. | |||
Intended status: Standards Track June 20, 2023 | Intended status: Standards Track November 6, 2023 | |||
Expires: December 22, 2023 | Expires: May 9, 2024 | |||
HTTP Proxy-Status Parameter for Next-Hop Aliases | HTTP Proxy-Status Parameter for Next-Hop Aliases | |||
draft-ietf-httpbis-alias-proxy-status-05 | draft-ietf-httpbis-alias-proxy-status-latest | |||
Abstract | Abstract | |||
This document defines the "next-hop-aliases" HTTP Proxy-Status | This document defines the "next-hop-aliases" HTTP Proxy-Status | |||
Parameter. This parameter carries the list of aliases and canonical | Parameter. This parameter carries the list of aliases and canonical | |||
names an intermediary received during DNS resolution as part | names an intermediary received during DNS resolution as part of | |||
establishing a connection to the next hop. | establishing a connection to the next hop. | |||
About This Document | About This Document | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Status information for this document may be found at | Status information for this document may be found at | |||
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-alias-proxy- | <https://datatracker.ietf.org/doc/draft-ietf-httpbis-alias-proxy- | |||
status/>. | status/>. | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
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 December 22, 2023. | This Internet-Draft will expire on May 9, 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2023 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 2, line 28 ¶ | skipping to change at page 2, line 28 ¶ | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. next-hop-aliases Parameter . . . . . . . . . . . . . . . . . 3 | 2. next-hop-aliases Parameter . . . . . . . . . . . . . . . . . 3 | |||
2.1. Encoding special characters . . . . . . . . . . . . . . . 4 | 2.1. Encoding special characters . . . . . . . . . . . . . . . 4 | |||
3. Implementation Considerations . . . . . . . . . . . . . . . . 5 | 3. Implementation Considerations . . . . . . . . . . . . . . . . 5 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . 7 | 6.2. Informative References . . . . . . . . . . . . . . . . . 7 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
1. Introduction | 1. Introduction | |||
The Proxy-Status HTTP response field [PROXY-STATUS] allows | The Proxy-Status HTTP response field [PROXY-STATUS] allows | |||
intermediaries to convey information about how they handled the | intermediaries to convey information about how they handled the | |||
request in HTTP responses sent to clients. It defines a set of | request in HTTP responses sent to clients. It defines a set of | |||
parameters that provide information, such as the name of the next | parameters that provide information, such as the name of the next | |||
hop. | hop. | |||
[PROXY-STATUS] defines a "next-hop" parameter, which can contain a | [PROXY-STATUS] defines a "next-hop" parameter, which can contain a | |||
skipping to change at page 3, line 29 ¶ | skipping to change at page 3, line 29 ¶ | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. next-hop-aliases Parameter | 2. next-hop-aliases Parameter | |||
The "next-hop-aliases" parameter's value is a String | The "next-hop-aliases" parameter's value is a String | |||
[STRUCTURED-FIELDS] that contains one or more DNS names in a comma- | [STRUCTURED-FIELDS] that contains one or more DNS names in a comma- | |||
separated list. The items in the list include all alias names and | separated list. The items in the list include all alias names and | |||
canonical names received in CNAME records [DNS] during the course of | canonical names received in CNAME records [DNS] during the course of | |||
resolving the next hop's hostname using DNS, not including the | resolving the next hop's hostname using DNS, and MAY include the | |||
original requested hostname itself. The names SHOULD appear in the | original requested hostname itself. The names SHOULD appear in the | |||
order in which they were received in DNS. If there are multiple | order in which they were received in DNS. If there are multiple | |||
CNAME records in the chain, the first name in the "next-hop-aliases" | CNAME records in the chain, the first name in the "next-hop-aliases" | |||
list would be the value in the CNAME record for the original | list would be the value in the CNAME record for the original | |||
hostname, and the final name in the "next-hop-aliases" list would be | hostname, and the final name in the "next-hop-aliases" list would be | |||
the name that ultimately resolved to one or more addresses. | the name that ultimately resolved to one or more addresses. | |||
The list of DNS names in "next-hop-aliases" uses a comma (",") as a | The list of DNS names in "next-hop-aliases" uses a comma (",") as a | |||
separator between names. Note that if a comma is included in a name | separator between names. Note that if a comma is included in a name | |||
itself, the comma must be encoded as described in Section 2.1. | itself, the comma must be encoded as described in Section 2.1. | |||
skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 15 ¶ | |||
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; | Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; | |||
next-hop-aliases="tracker.example.com,service1.example.com" | next-hop-aliases="tracker.example.com,service1.example.com" | |||
This indicates that proxy.example.net, which used the IP address | This indicates that proxy.example.net, which used the IP address | |||
"2001:db8::1" as the next hop for this request, encountered the names | "2001:db8::1" as the next hop for this request, encountered the names | |||
"tracker.example.com" and "service1.example.com" in the DNS | "tracker.example.com" and "service1.example.com" in the DNS | |||
resolution chain. Note that while this example includes both the | resolution chain. Note that while this example includes both the | |||
"next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can | "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can | |||
be included without including "next-hop". | be included without including "next-hop". | |||
The proxy can also include the name of the next hop as the first item | ||||
in the list. This is particularly useful for reverse proxies when | ||||
clients would not otherwise know the name of the next hop, and the | ||||
"next-hop" header is used to convey an IP address. | ||||
For example, consider a proxy "reverseproxy.example.net" that | ||||
receives the following records when performing DNS resolution for the | ||||
next hop "host.example.com": | ||||
host2.example.com. CNAME service2.example.com. | ||||
service2.example.com. AAAA 2001:db8::2 | ||||
The proxy could include the following proxy status in its response: | ||||
Proxy-Status: reverseproxy.example.net; next-hop="2001:db8::2"; | ||||
next-hop-aliases="host2.example.com,service2.example.com" | ||||
The "next-hop-aliases" parameter only applies when DNS was used to | The "next-hop-aliases" parameter only applies when DNS was used to | |||
resolve the next hop's name, and does not apply in all situations. | resolve the next hop's name, and does not apply in all situations. | |||
Clients can use the information in this parameter to determine how to | Clients can use the information in this parameter to determine how to | |||
use the connection established through the proxy, but need to | use the connection established through the proxy, but need to | |||
gracefully handle situations in which this parameter is not present. | gracefully handle situations in which this parameter is not present. | |||
The proxy MAY send the empty string ("") as the value of "next-hop- | The proxy MAY send the empty string ("") as the value of "next-hop- | |||
aliases" to indicate that no CNAME records were encountered when | aliases" to indicate that no CNAME records were encountered when | |||
resolving the next hop's name. | resolving the next hop's name. | |||
skipping to change at page 5, line 8 ¶ | skipping to change at page 5, line 25 ¶ | |||
character itself will be percent-encoded, the name | character itself will be percent-encoded, the name | |||
"dot\.label.example.com" would be encoded within a "next-hop-aliases" | "dot\.label.example.com" would be encoded within a "next-hop-aliases" | |||
parameter as follows: | parameter as follows: | |||
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; | Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; | |||
next-hop-aliases="dot%5C.label.example.com,service1.example.com" | next-hop-aliases="dot%5C.label.example.com,service1.example.com" | |||
Upon parsing this name, "dot%5C.label" MUST be treated as a single | Upon parsing this name, "dot%5C.label" MUST be treated as a single | |||
label. | label. | |||
Similarly the "\" character in a label MUST be escaped as "\\". | Similarly the "\" character in a label MUST be escaped as "\\" and | |||
Other uses of "\" MUST NOT appear in the label after percent- | then percent-encoded. Other uses of "\" MUST NOT appear in the label | |||
decoding. | after percent-decoding. For example, if there is a DNS name | |||
"backslash\name.example.com", it would first be escaped as | ||||
"backslash\\name.example.com", and then percent-encoded as follows: | ||||
Proxy-Status: proxy.example.net; next-hop="2001:db8::1"; | ||||
next-hop-aliases="backslash%5C%5Cname.example.com,service1.example.com" | ||||
3. Implementation Considerations | 3. Implementation Considerations | |||
In order to include the "next-hop-aliases" parameter, a proxy needs | In order to include the "next-hop-aliases" parameter, a proxy needs | |||
to have access to the chain of alias names and canonical names | to have access to the chain of alias names and canonical names | |||
received in CNAME records. | received in CNAME records. | |||
Implementations ought to note that the full chain of names might not | Implementations ought to note that the full chain of names might not | |||
available in common DNS resolution APIs, such as "getaddrinfo". | be available in common DNS resolution APIs, such as "getaddrinfo". | |||
"getaddrinfo" does have an option for "AI_CANONNAME", but this will | "getaddrinfo" does have an option for "AI_CANONNAME" (Section 6.1 of | |||
only return the last name in the chain (the canonical name), not the | [RFC3493]), but this will only return the last name in the chain (the | |||
alias names. | canonical name), not the alias names. | |||
An implementation MAY include incomplete information in the "next- | An implementation MAY include incomplete information in the "next- | |||
hop-aliases" parameter to accommodate cases where it is unable to | hop-aliases" parameter to accommodate cases where it is unable to | |||
include the full chain, such as only including the canonical name if | include the full chain, such as only including the canonical name if | |||
the implementation can only use "getaddrinfo" as described above. | the implementation can only use "getaddrinfo" as described above. | |||
4. Security Considerations | 4. Security Considerations | |||
The "next-hop-aliases" parameter does not include any DNSSEC | The "next-hop-aliases" parameter does not include any DNSSEC | |||
information or imply that DNSSEC was used. The information included | information or imply that DNSSEC was used. The information included | |||
skipping to change at page 7, line 24 ¶ | skipping to change at page 7, line 44 ¶ | |||
6.2. Informative References | 6.2. Informative References | |||
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, | [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, | |||
DOI 10.17487/RFC6265, April 2011, | DOI 10.17487/RFC6265, April 2011, | |||
<https://www.rfc-editor.org/info/rfc6265>. | <https://www.rfc-editor.org/info/rfc6265>. | |||
[RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. | ||||
Stevens, "Basic Socket Interface Extensions for IPv6", | ||||
RFC 3493, DOI 10.17487/RFC3493, February 2003, | ||||
<https://www.rfc-editor.org/info/rfc3493>. | ||||
Author's Address | Author's Address | |||
Tommy Pauly | Tommy Pauly | |||
Apple, Inc. | Apple, Inc. | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
End of changes. 11 change blocks. | ||||
15 lines changed or deleted | 42 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/ |