Re: [whatwg/fetch] Elaborate on obtaining a connection (#1245)

@MattMenke2 commented on this pull request.



> +<a for=/>IP addresses</a>. If this operation succeeds, return the <a for=/>set</a> of
+<a for=/>IP addresses</a>. If it fails, return failure. The results of this operation may be cached.
+If they are cached, <var>key</var> must be used as part of the cache key.
+
+<p class=note>Typically this operation would involve DNS. The particulars (apart from the cache key)
+are not tied down as they are not pertinent to the system the Fetch Standard establishes. Other
+documents ought not to build on this primitive without having a considered discussion with the Fetch
+Standard community first. [[RFC1035]]
+
+<p>To <dfn>resolve an origin</dfn>, given an <a for=/>origin</a> <var>origin</var> and a
+<a for=/>network partition key</a> <var>key</var>:
+<!-- Should we assert the scheme here to be an HTTP(S) scheme or a WebRTC scheme? -->
+
+<ol>
+ <li><p>If <var>origin</var>'s <a for=origin>host</a> is an <a for=/>IP address</a>, then return
+ « <var>origin</var>'s <a for=origin>host</a> ».

Note that IP Address is defined as a 32-bit or 128-bit unsigned integer.  Neither of those are a valid host.  Is there some host to IP address mapping we should reference in the line above and here?

> +
+<p class=note>Typically this operation would involve DNS. The particulars (apart from the cache key)
+are not tied down as they are not pertinent to the system the Fetch Standard establishes. Other
+documents ought not to build on this primitive without having a considered discussion with the Fetch
+Standard community first. [[RFC1035]]
+
+<p>To <dfn>resolve an origin</dfn>, given an <a for=/>origin</a> <var>origin</var> and a
+<a for=/>network partition key</a> <var>key</var>:
+<!-- Should we assert the scheme here to be an HTTP(S) scheme or a WebRTC scheme? -->
+
+<ol>
+ <li><p>If <var>origin</var>'s <a for=origin>host</a> is an <a for=/>IP address</a>, then return
+ « <var>origin</var>'s <a for=origin>host</a> ».
+
+ <li><p>If the user agent is configured to use a proxy, then return
+ « <var>origin</var>'s <a for=origin>host</a> ».

In the case of a proxy, do we still need to resolve IP addresses?  I don't believe Chrome currently does (in, e.g., the RFC 1918 case)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1245#pullrequestreview-674367166