Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119427 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3153 invoked from network); 27 Jan 2023 16:06:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Jan 2023 16:06:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C9AC7180088 for ; Fri, 27 Jan 2023 08:06:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 27 Jan 2023 08:06:29 -0800 (PST) Received: by mail-wr1-f46.google.com with SMTP id m14so4933419wrg.13 for ; Fri, 27 Jan 2023 08:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadoghq.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=msj7yUOsgKO7EtDztiO/psMjPx9M4MkLO7pn5gKKzJc=; b=IetnHLjpxx5hJXSRcgjBWssN3wh3O7CQTrgnmJeA+sxHLkm7LbkftK7k3d05YUKQel J0Hx++d6ytGnz1UglgD//skgdenNVkvrrmIggn3WDBhdNDtRPF5+hNeGNWsjW/TC0FqE RPGZpwbJ1rLiwQO56YMhCK4QbxFpcHcjvAFCA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=msj7yUOsgKO7EtDztiO/psMjPx9M4MkLO7pn5gKKzJc=; b=H32SLtQY4ccm5N9bjDfx2Fdi1RMHLjLtFDzFNxOJ3L8LgsGhWoqXVxMEkzJMaim8Wy qWc3HddNRc2JY8vBDnMBJr62O/qMoXLtiqKkNqMPYVitK7DmipsOdpwR4y3h79MQou6T WPpI984Y3T6GoMc8nTOKUIDeTw8I8YB5adIc1SmJf/RWMb/aOX3+4VdR02Bs4aEpNjwb /ccW0hVVDTMstoOK5RaccvguJOIFud++6eLiyVIYKMIetoXsm9lkB+A8gAoyyTCoNnl8 op/fG4nPvTpoYOon5Vq3a9x3XbT/O2+AzYugrottUaKjRsz/FDuhnaj95eQn0jNrKcQ/ nb4w== X-Gm-Message-State: AFqh2kotusHihMDw1D2oIWkf5/hewRHo5eeH1gX6EMmAY0lkZESnRezn hNkHP/lGibo+ljPrq+/RVeoqOP+Jug7GPdSt/BddhmFBK0VBIA== X-Google-Smtp-Source: AMrXdXtkabfZ7lGtZBKMwqJ9xUfnW3GFchEghcQF+3Z/wZFkz6AsSoFNknpih72GDAtnWGdtTFJu8Ym7pcW/e2S1kqo= X-Received: by 2002:a5d:58c2:0:b0:2be:1672:7490 with SMTP id o2-20020a5d58c2000000b002be16727490mr1095269wrf.189.1674835588036; Fri, 27 Jan 2023 08:06:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: Levi Morrison Date: Fri, 27 Jan 2023 09:06:16 -0700 Message-ID: To: Larry Garfield Cc: php internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments From: internals@lists.php.net ("Levi Morrison via internals") On Fri, Jan 27, 2023 at 8:54 AM Larry Garfield wrote: > > On Fri, Jan 27, 2023, at 3:00 AM, Andreas Heigl wrote: > > Hey Folks. > > > > I think it would be a good idea to deprecate calling ldap_connect with 2 > > parameters host and port. > > > > Wait: What? > > > > Currently there are three ways one can call ldap_connect. > > > > 1. With a string $ldap_uri > > 2. With a string $host and an int $port, > > 3. With even more parameters for those that did compile PHP with OracleLDAP. > > > > The 3rd way of calling it is not even documented in the docs as it is a > > very niche edge-case that would only confuse most people. > > > > The 2nd way of calling the function is based on the since some years > > deprecated underlying ldap_open function. Internally we already moved to > > the underlying ldap_initialize-function that requires passing an > > LDAP-URI. For that we are already converting the passed host and port > > into an LDAP-URI of the form 'ldap://$host:$port'. > > > > This already illustrates one of the issues that this way of calling the > > function implies: It is not possible to use ldaps as a schema using that > > way of calling ldap_connect as it will always use ldap as schema. No > > matter which port is passed. > > > > A second reason why I think we should deprecate calling ldap_connect > > with two parameters is, that it does not allow one to pass multiple > > ldap-servers as it is possible using the LDAP-URI. > > > > This is for sure a BC-break but in my opinion a rather small one as > > there are not many users actually using it and there is a clear and easy > > migration path for those that use it: Instead of calling > > > > ldap_connect($host, $port) > > > > one calls > > > > ldap_connect("ldap://$host:$port??369") > > > > Also most of the users should not be affected at all as they are using > > 3rd party libraries that are already only using an LDAP-URI when calling > > ldap_connect like Laminas\Ldap or Symfony\Ldap > > > > The documentation at https://www.php.net/ldap_connect also explicitly > > states (for some time by now) that using host and port is considered > > deprecated. > > > > Named parameters btw also only support ldap_connect(uri: > > 'ldap://example.com') and ldap_connect(host:'example.com', port:369) > > will throw an error. > > > > There already is a PR open[1] that implements the deprecation so that > > for the upcoming PHP8 releases each call to ldap_connect with 2 > > parameters would emit a deprecation message so that people have enough > > time to adapt their code before we can actually remove using two > > parameters in the next major release. > > > > Thanks for your comments. > > > > Cheers > > > > Andreas > > > > [1] https://github.com/php/php-src/pull/5177 > > This would require an RFC, obviously, but it seems reasonable to me. "Variable meaning parameters" was always a bad idea, and cleaning them up is a good idea. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > I disagree that this needs an RFC. The docs have long-said it's deprecated; adding a deprecation message _in code_ to match shouldn't require an RFC.