php / php/php-src

Multiple entries for PHP-FPMs listen directive

Aperta
#11,593 1 commento 2 reazioni 1 assegnatario Vedi su GitHub

@bukka ci sta già lavorando.

Dal 4/7/2023.

Feature SAPI: fpm Status: Needs Triage
Lingua principale
C
Stelle
40.4k
Fork
8.1k
Merge medio
2g 13h
PR unite (30g)
96

Descrizione

Description

Currently, PHP-FPM provides limited options for defining the host address, restricting it to either no host, an IPv4 address, or an IPv6 address. Here are the existing configurations and their limitations:

  1. listen = 9000 (IPv4 and IPv6, but accessible from all sources)
    This configuration allows PHP-FPM to listen on both IPv4 and IPv6 addresses, but it lacks the ability to specify a particular host.

  2. listen = 127.0.0.1:9000 (accessible only locally via IPv4)
    PHP-FPM can be accessed locally using IPv4, but it does not support IPv6 connections.

  3. listen = [::1]:9000 (accessible only locally via IPv6)
    Enables local accessibility through IPv6, but it does not support IPv4 connections.

  4. listen = localhost:9000 (binds to IPv4 only)
    This configuration restricts PHP-FPM to bind exclusively to IPv4 in my case.

The current limitations force users to make compromises. One possible solution is to globally set PHP-FPM to listen on port 9000 and control access through firewall rules or the listen.allowed_clients directive. However, it is desirable to have firewall-independent configurations and ensure closed internet access.

To address this, I propose introducing support for multiple interfaces in the PHP-FPM configuration:

listen = 127.0.0.1:9000, [::1]:9000

This configuration would allow PHP-FPM to listen on both IPv4 (127.0.0.1) and IPv6 ([::1]) addresses simultaneously, providing full control over the interfaces while maintaining full backwards-compatibility.

Alternatively, another solution could involve introducing a "port" directive and making the port specification optional within the listen directive:

listen = 127.0.0.1, [::1]
port = 9000

By implementing either of these solutions, clients can choose the most suitable approach based on their requirements and preferences.

This enhancement would also allow system administrators - particularly nginx upstream users with split configurations - to use "localhost" as a reliable target and leave it up to nginx/dns resolver/system settings to determine the IP version instead of "hard-coding" it into dozens - if not hundred - of files.

Please kindly consider my request.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.