shinrich opened a new pull request #7276: URL: https://github.com/apache/trafficserver/pull/7276
Ran into this while working through the outbound connection logic. The comments and logic around try_to_expand_host_name seemed odd, and I didn't see any relevant configuration. I found some old 4.1.x documentation stashed on the internet which pointed me to proxy.config.http.enable_url_expandomatic, and from there got to @reveller's PR #918 which removed the configuration for this feature. Cool name, but confusing feature. This PR removes the last confusing implementation remnants of this feature. I may have gone a bit too far in the parent selection case (the only case that did anything in the try_to_expand_host_name method), so I would appreciate some eyes on from parent selection experts like @rob05c, @ezelkow1 and @randall. From within HttpTransact::OSDNSLookup, I inlined the remaining logic of try_to_expand_host_name, which is to always fail if is not a parent lookup. Then I remembered that there is a parallel parent version of this method, HttpTransact::PPDNSLookup, so I removed the retry logic entirely. There was a static max_dns_lookups = 3 within the OSDNSLookup method, and the dns_info has an attempts member. I removed both of those on the assumption that the parent selection does not go through OSDNSLookup, so it will not trigger the logic to do a DNS lookup on the hostname instead of the parent name. If this functionality is indeed used, I will add it back. In terms of DNS retries, that is handled at the DNS level and controlled by the config proxy.config.dns.retries. If we are not changing the name and re-issuing the DNS request, we can also get rid of the logic that returns a redirect if the name change lookup succeeded. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
