Please proceed with this one! The change is reasonable since the "dual-stack endpoint" conforms to a pre-defined shape.
I was pointing out that parse_url currently rejects urls that does not conform to the pre-defined shapes. To support "dual-stack endpoint", we have to add it as a approved shape. Alternatively, we can allow parse_url to passthrough any given url it does not recognize and set self.endpoint accordingly. This way, perhaps we did not need to add the special logic for "dual-stack endpoint" and can also future proof any other url format AWS decides to create.
This was an idea based on #711 where we once again had to allowlist a pre-defined shape into the url parsing logic for Azure/OneLake.
Originally posted by @kevinjqliu in #780 (comment)
Please proceed with this one! The change is reasonable since the "dual-stack endpoint" conforms to a pre-defined shape.
I was pointing out that
parse_urlcurrently rejects urls that does not conform to the pre-defined shapes. To support "dual-stack endpoint", we have to add it as a approved shape. Alternatively, we can allowparse_urlto passthrough any givenurlit does not recognize and setself.endpointaccordingly. This way, perhaps we did not need to add the special logic for "dual-stack endpoint" and can also future proof any other url format AWS decides to create.This was an idea based on #711 where we once again had to allowlist a pre-defined shape into the url parsing logic for Azure/OneLake.
Originally posted by @kevinjqliu in #780 (comment)