On Wed, Jun 6, 2012 at 1:09 AM, Magnus Hagander <mag...@hagander.net> wrote: > On Wed, Jun 6, 2012 at 4:38 AM, Daniel Farina <dan...@heroku.com> wrote: >> On Tue, Jun 5, 2012 at 6:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Daniel Farina <dan...@heroku.com> writes: >> If that is the case, is there a convention we can use to separate the >> parts of the connection string (in both representations) into the >> parts sent to the server and the part that the client needs? We >> already abuse this a little bit because URI syntax (in general, not >> just our rendition of it) leaves little room for extension for >> parameters on the client side. Consider ?sslmode=require. >> >> In both representations, the net effect of a typo would be that >> instead of magically reading some properties on the client side, >> they'd be sent to the server. How often is this going to be so wrong >> that one cannot send a response from the server indicating to the user >> their error? On casual inspection it doesn't seem like prohibitively >> often, but I haven't mulled over that for very long. > > I think that's an excellent example of this being a bad idea. If you > mis-spell sslmode=require, that should absolutely result in an error > on the client side. Otherwise, you might end up sending your password > (or other details that are not as sensitive, but still sensitive) over > an unencrypted connection. If you wait for the error from the server, > it's too late.
That is an excellent point. Is there enough time in the day to gripe about how sslmode=require is not the default? Well, this seems pretty obviated by the prefix-naming convention, but it's an iron clad example of how the older idea was a bad one. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
