You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the tracker for existing similar issues and I know that duplicates will be closed
Describe the Issue
This is somewhat related to issue #10221 - but I'm hoping this description provides a bit more insight and perhaps a slightly different resolution.
As hosts adopt IPv6, when resolving a hostname, it's common to receive two IP responses from DNS; one with an IPv4 address and another with IPv6. An "ANY" query (dig, etc.) for google.com as an example, results in both 'A' and 'AAAA' records being returned. Additionally, when "localhost" is resolved, it also frequently has both an 'A' and 'AAAA' record.
In this scenario, Postman is seeing the IPv6 record and connects to the host, seemingly to "taste test" the IPv6 address. If the IPv6 port has a successful connection, Postman closes the connection (or just acts like it doesn't have data to send, not sure) and opens a second connection proceeding with the full request to the IPv6 address. If the initial test connection fails, Postman moves on to attempting the IPv4 address instead.
The double connection is unnecessary (and even confusing). It's perfectly fine that Postman prefers the IPv6 address and attempts a connection to the socket. But it's unnecessary that Postman closes that connection and then reopens it back to the same IPv6 host/port.
Instead, Postman should just assume that the connection to IPv6 is going to work and can send the full request immediately. If the IPv6 connection fails, Postman can simply move on attempting an IPv4 connection. There's no need for Postman to "test" if the IPv6 connection would succeed.
So the end result would be that Postman doesn't open a speculative connection just to test if an IPv6 connection would succeed. Instead it simply connects like it would an IPv4 socket, as if it would work, and sends the request when the connection is established. If the connection to the IPv6 address doesn't succeed, then it can then try the IPv4 socket instead.
Steps To Reproduce
Use Postman to connect to a server that has a socket listening for both IPv6 and IPv4 connections.
Ensure that DNS resolves addresses for both protocols. Localhost commonly does this on modern systems.
Monitor the server connection logs (or appropriate tracing information).
Note that Postman connects to the IPv6 socket twice (once to "test" it, once to deliver the payload).
Screenshots or Videos
No response
Operating System
Mac
Postman Version
10.17.4
Postman Platform
Postman App
User Account Type
Signed In User
Additional Context?
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Describe the Issue
This is somewhat related to issue #10221 - but I'm hoping this description provides a bit more insight and perhaps a slightly different resolution.
As hosts adopt IPv6, when resolving a hostname, it's common to receive two IP responses from DNS; one with an IPv4 address and another with IPv6. An "ANY" query (dig, etc.) for google.com as an example, results in both 'A' and 'AAAA' records being returned. Additionally, when "localhost" is resolved, it also frequently has both an 'A' and 'AAAA' record.
In this scenario, Postman is seeing the IPv6 record and connects to the host, seemingly to "taste test" the IPv6 address. If the IPv6 port has a successful connection, Postman closes the connection (or just acts like it doesn't have data to send, not sure) and opens a second connection proceeding with the full request to the IPv6 address. If the initial test connection fails, Postman moves on to attempting the IPv4 address instead.
The double connection is unnecessary (and even confusing). It's perfectly fine that Postman prefers the IPv6 address and attempts a connection to the socket. But it's unnecessary that Postman closes that connection and then reopens it back to the same IPv6 host/port.
Instead, Postman should just assume that the connection to IPv6 is going to work and can send the full request immediately. If the IPv6 connection fails, Postman can simply move on attempting an IPv4 connection. There's no need for Postman to "test" if the IPv6 connection would succeed.
So the end result would be that Postman doesn't open a speculative connection just to test if an IPv6 connection would succeed. Instead it simply connects like it would an IPv4 socket, as if it would work, and sends the request when the connection is established. If the connection to the IPv6 address doesn't succeed, then it can then try the IPv4 socket instead.
Steps To Reproduce
Screenshots or Videos
No response
Operating System
Mac
Postman Version
10.17.4
Postman Platform
Postman App
User Account Type
Signed In User
Additional Context?
No response
The text was updated successfully, but these errors were encountered: