At Wed, 2 Feb 2022 19:46:13 +0000, Jacob Champion <pchampion@vmware.com> wrote in
> On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > +#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?
I don't think it should be a part of port.h. Though I suggested
frontend-only header file by the name, isn't it enough to separate out
the definitions from utils/inet.h to common/inet-common.h then include
the inet-common.h from inet.h?
> > 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.
Hmm. Well, considering that the objective for the validation is to
check if the server is actually the client is intending to connect, it
is fine. Sorry for the noise.
> (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.)
Yeah.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center