[Repost from July 1. Hasn't made it to the list yet.]
The description of the FE/BE protocol says:
| The postmaster uses this info and the contents of the pg_hba.conf file
| to determine what authentication method the frontend must use. The
| postmaster then responds with one of the following messages:
[...]
| If the frontend does not support the authentication method requested by
| the postmaster, then it should immediately close the connection.
However, libpq doesn't do that. Instead, it leaves the connection open
and returns CONNECTION_BAD to the client. The client would then
presumably call something like PQfinish(), which sends a Terminate message
and closes the connection. This happened to not confuse the <=7.1
postmasters because they were waiting for 4 bytes and treated the early
connection close appropriately.
On this occasion let me also point out that
pqPuts("X", conn);
is not the way to send a single byte 'X' to the server. I see the JDBC
driver goes through troubles to make the same mistake.
In current sources the backends do the authentication and use the pqcomm.c
functions for communication, but those aren't that happy about the early
connection close:
pq_recvbuf: unexpected EOF on client connection FATAL 1: Password authentication failed for user 'peter' pq_flush:
send()failed: Broken pipe
So I figured I would sneak in a check for connection close before reading
the authentication response in the server, but since the frontends seems
to be doing what they want I don't really know what to check for.
Should I fix libpq to follow the docs in this and on the server's end make
anything that's not either a connection close or a valid authentication
response as "unexpected EOF"? That way old clients would produce a bit of
noise in the server log.
Does anyone know how the ODBC and JDBC drivers handle this situation?
Btw., is recv(sock, x, 1, MSG_PEEK) == 0 an appropriate way to check for a
closed connection without reading anything?
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
