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

@sleevi commented on this pull request.



> @@ -2204,6 +2204,39 @@ unset or <a for=request>keepalive</a> is false, <a lt=terminated for=fetch>termi
 <a for="fetch group">fetch record</a>'s <a for="fetch record">fetch</a>.
 
 
+<h3 id=resolving-domains>Resolving domains</h3>
+
+<p>To <dfn>resolve a domain</dfn>, given a <a for=/>domain</a> <var>domain</var> and a
+<a for=/>network partition key</a> <var>key</var>, perform an <a>implementation-defined</a>
+operation to turn <var>domain</var> into a <a for=/>set</a> of one or more
+<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.

I'm not sure this line makes sense, or at least, not normative sense.

The issue here is that unless you're writing your own recursive resolver implementation, the resolvers you communicate with will ignore `key` and cache. E.g. if you use an OS API and the OS API caches, it's not going to consider `key`. And even if you write your own recursive resolver, you can't be sure that the name servers themselves won't cache based on `(host, recordtype)` tuples, ignoring `key` (which is never on the wire)

While this is definitely more of @MattMenke2 's realm for wording, I wanted to flag this, because it seems like this might involve some form of note or form of [RFC 6919 language](https://datatracker.ietf.org/doc/html/rfc6919#section-1).

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

It depends on the type of proxy being used. We do resolve hosts for some proxies (e.g. SOCKSv4), but not for others (e.g. HTTP CONNECT). And we may still need to resolve prior to a proxy being involved (e.g. a PAC script)

I think we should strip the proxy-particular language here with regards to resolving; it's more closely tied to the connection establishment logic, and I think we'd have to tackle it there. That said, I'm not 100% sure on that - I think it really depends on how we end up using this "method" here that dictates which parts are captured in the pseudocode.

-- 
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-674382787