commit d70cb5ad8e25a9068a28d2ba63562ebc81387fef
parent 0fe80404c0cf1a7f199cecc6242efbfa0eaaf15f
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 20 May 2022 20:13:52 +0200
better formatting
Diffstat:
1 file changed, 40 insertions(+), 24 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -3309,38 +3309,48 @@ Value Symbol Symbol
<section>
<name>Virtual Hosting</name>
<t>
- HTTP virtual hosting and TLS Server Name Indication are common
- use cases on the Web.
- The HTTP client such as a browser supplies a DNS name in the HTTP
- "Host"-header or the TLS handshake, respectively.
- This allows the HTTP server to serve the indicated virtual host
- with a matching TLS handshake.
- Any resource record in GNS can be represented as a concatenation of
- of a GNS label and the zTLD of the zone.
- While not human-readable, this property of GNS names can be
- leveraged in order to facilitate the same use cases.
- </t>
- <t>
+ HTTP virtual hosting and TLS Server Name Indication are common
+ use cases on the Web.
+ The HTTP client such as a browser supplies a DNS name in the HTTP
+ "Host"-header or the TLS handshake, respectively.
+ This allows the HTTP server to serve the indicated virtual host
+ with a matching TLS handshake.
+ The unambiguity of DNS names are a prerequisite of those use cases.
+ </t>
+ <t>
+ GNS names are not globally unique.
+ But, any resource record in GNS can unambiguously be represented as a
+ concatenation of of a GNS label and the zTLD of the zone.
+ While not human-readable, this property of GNS names can be
+ leveraged in order to facilitate the same use cases.
+ </t>
+ <t>
Consider the GNS name "www.example.gns" entered in a GNS-aware
HTTP client.
At first, "www.example.gns" is resolved using GNS yielding a record
set.
- Then, the HTTP client first determines the virtual host as follows:
+ Then, the HTTP client determines the virtual host as follows:
+ </t>
+ <t>
+ If there is a LEHO record (<xref target="gnsrecords_leho"/>) in
+ the record set, then the HTTP client uses the record value in the
+ "Host"-header field of the HTTP request:
</t>
- <ol>
- <li>If there is a LEHO record (<xref target="gnsrecords_leho"/>) in
- the record set, then the HTTP client uses the record value in the
- "Host"-header field of the HTTP request. Example:
- "Host: www.example.com".</li>
- <li>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+GET / HTTP/1.1
+Host: www.example.com
+ ]]></artwork>
+ <t>
If there is no LEHO record in the record set,
then the HTTP client tries to find the zone of the record
and translates the GNS name into an unabiguous
zTLD-representation before using it in the "Host"-header field of
- the HTTP request. Example:
- "Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
- </li>
- </ol>
+ the HTTP request:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+GET / HTTP/1.1
+Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+ ]]></artwork>
<t>
In order to determine a canonical representation of the record with
a zTLD, at most two queries are required:
@@ -3348,7 +3358,13 @@ Value Symbol Symbol
a zone delegation record which would imply that the record set which
was originally resolved is published under the apex label.
If it does, the unique GNS name is simply the zTLD representation
- of the delegated zone: "Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
+ of the delegated zone:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+GET / HTTP/1.1
+Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+ ]]></artwork>
+ <t>
If it does not, the unique GNS name is the concatenation of the
label "www" and the zTLD representation of the zone as given in the
example above.
