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

@MattMenke2 commented on this pull request.



> +
+<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> ».

No, I mean resolve the IP address.  e.g., mapping https://127.0.0.1/ to 0xFF000001 (sorry, may have the order flipped there).  Chrome, at least, only tracks the proxy's IP in this case, and only provides that to consumers.  Consumers are careful not to treat it as the server IP.  So this would require a rearchitecture a number of Chrome layers.  Consumers would either have to extract the IP from the URL in the proxy case, or Chrome's network stack would have to provide both IPs, and all consumers audited.

-- 
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#discussion_r644097119