On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote: > However, 0002, > > +/* > + * In a frontend build, we can't include inet.h, but we still need to have > + * sensible definitions of these two constants. Note that pg_inet_net_ntop() > + * assumes that PGSQL_AF_INET is equal to AF_INET. > + */ > +#define PGSQL_AF_INET (AF_INET + 0) > +#define PGSQL_AF_INET6 (AF_INET + 1) > + > > Now we have the same definition thrice in frontend code. Coulnd't we > define them in, say, libpq-fe.h or inet-fe.h (nonexistent) then > include it from the three files?
I started down the inet-fe.h route, and then realized I didn't know where that should go. Does it need to be included in (or part of) port.h? And should it be installed as part of the logic in src/include/Makefile? > +$node->connect_fails( > + "$common_connstr host=192.0.2.2", > + "host not matching an IPv4 address (Subject Alternative Name 1)", > > It is not the real IP address of the server. > > https://datatracker.ietf.org/doc/html/rfc6125 > > In some cases, the URI is specified as an IP address rather than a > > hostname. In this case, the iPAddress subjectAltName must be > > present in the certificate and must exactly match the IP in the URI. > > When IP address is embedded in URI, it won't be translated to another > IP address. Concretely https://192.0.1.5/hoge cannot reach to the host > 192.0.1.8. On the other hand, as done in the test, libpq allows that > when "host=192.0.1.5 hostaddr=192.0.1.8". I can't understand what we > are doing in that case. Don't we need to match the SAN IP address > with hostaddr instead of host? I thought that host, not hostaddr, was the part that corresponded to the URI. So in a hypothetical future where postgresqls:// exists, the two URIs postgresqls://192.0.2.2:5432/db postgresqls://192.0.2.2:5432/db?hostaddr=127.0.0.1 should both be expecting the same certificate. That seems to match the libpq documentation as well. (Specifying a host parameter is also allowed... that seems like it could cause problems for a hypothetical postgresqls:// scheme, but it's probably not relevant for this thread.) --Jacob
