gh-123832: Adjust `socket.getaddrinfo` docs for better POSIX compliance (GH-126182)

* gh-123832: Adjust `socket.getaddrinfo` docs for better POSIX compliance

This changes nothing changes for CPython supported platforms,
but hints how to deal with platforms that stick to the letter of
the spec.
It also marks `socket.getaddrinfo` as a wrapper around `getaddrinfo(3)`;
specifically, workarounds to make the function work consistently across
platforms are out of scope in its code.

Include wording similar to the POSIX's “by providing options and by
limiting the returned information”, which IMO suggests that the
hints limit the resulting list compared to the defaults, *but* can
be interpreted differently. Details are added in a note.

Specifically say that this wraps the underlying C function. So, the
details are in OS docs. The “full range of results” bit goes away.

Use `AF_UNSPEC` rather than zero for the *family* default, although
I don't think a system where it's nonzero would be very usable.

Suggest setting proto and/or type (with examples, as the appropriate
values aren't obvious). Say why you probably want to do that that
on all systems; mention the behavior on the “letter of the spec”
systems.

Suggest that the results should be tried in order, which is,
AFAIK best practice -- see RFC 6724 section 2, and its predecessor
from 2003 (which are specific to IP, but indicate how people use this):

> Well-behaved applications SHOULD iterate through the list of
> addresses returned from `getaddrinfo()` until they find a working address.


Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
This commit is contained in:
Petr Viktorin 2024-11-14 09:31:14 +01:00 committed by GitHub
parent e0692f1165
commit ff0ef0a54b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 32 additions and 3 deletions

View File

@ -928,7 +928,9 @@ The :mod:`socket` module also offers various network-related services:
.. versionadded:: 3.7 .. versionadded:: 3.7
.. function:: getaddrinfo(host, port, family=0, type=0, proto=0, flags=0) .. function:: getaddrinfo(host, port, family=AF_UNSPEC, type=0, proto=0, flags=0)
This function wraps the C function ``getaddrinfo`` of the underlying system.
Translate the *host*/*port* argument into a sequence of 5-tuples that contain Translate the *host*/*port* argument into a sequence of 5-tuples that contain
all the necessary arguments for creating a socket connected to that service. all the necessary arguments for creating a socket connected to that service.
@ -938,8 +940,10 @@ The :mod:`socket` module also offers various network-related services:
and *port*, you can pass ``NULL`` to the underlying C API. and *port*, you can pass ``NULL`` to the underlying C API.
The *family*, *type* and *proto* arguments can be optionally specified The *family*, *type* and *proto* arguments can be optionally specified
in order to narrow the list of addresses returned. Passing zero as a in order to provide options and limit the list of addresses returned.
value for each of these arguments selects the full range of results. Pass their default values (:data:`AF_UNSPEC`, 0, and 0, respectively)
to not limit the results. See the note below for details.
The *flags* argument can be one or several of the ``AI_*`` constants, The *flags* argument can be one or several of the ``AI_*`` constants,
and will influence how results are computed and returned. and will influence how results are computed and returned.
For example, :const:`AI_NUMERICHOST` will disable domain name resolution For example, :const:`AI_NUMERICHOST` will disable domain name resolution
@ -959,6 +963,29 @@ The :mod:`socket` module also offers various network-related services:
:const:`AF_INET6`), and is meant to be passed to the :meth:`socket.connect` :const:`AF_INET6`), and is meant to be passed to the :meth:`socket.connect`
method. method.
.. note::
If you intend to use results from :func:`!getaddrinfo` to create a socket
(rather than, for example, retrieve *canonname*),
consider limiting the results by *type* (e.g. :data:`SOCK_STREAM` or
:data:`SOCK_DGRAM`) and/or *proto* (e.g. :data:`IPPROTO_TCP` or
:data:`IPPROTO_UDP`) that your application can handle.
The behavior with default values of *family*, *type*, *proto*
and *flags* is system-specific.
Many systems (for example, most Linux configurations) will return a sorted
list of all matching addresses.
These addresses should generally be tried in order until a connection succeeds
(possibly tried in parallel, for example, using a `Happy Eyeballs`_ algorithm).
In these cases, limiting the *type* and/or *proto* can help eliminate
unsuccessful or unusable connecton attempts.
Some systems will, however, only return a single address.
(For example, this was reported on Solaris and AIX configurations.)
On these systems, limiting the *type* and/or *proto* helps ensure that
this address is usable.
.. audit-event:: socket.getaddrinfo host,port,family,type,protocol socket.getaddrinfo .. audit-event:: socket.getaddrinfo host,port,family,type,protocol socket.getaddrinfo
The following example fetches address information for a hypothetical TCP The following example fetches address information for a hypothetical TCP
@ -978,6 +1005,8 @@ The :mod:`socket` module also offers various network-related services:
for IPv6 multicast addresses, string representing an address will not for IPv6 multicast addresses, string representing an address will not
contain ``%scope_id`` part. contain ``%scope_id`` part.
.. _Happy Eyeballs: https://en.wikipedia.org/wiki/Happy_Eyeballs
.. function:: getfqdn([name]) .. function:: getfqdn([name])
Return a fully qualified domain name for *name*. If *name* is omitted or empty, Return a fully qualified domain name for *name*. If *name* is omitted or empty,