Délais d'expiration

OxPHP applique deux délais d'expiration indépendants qui protègent contre les clients lents et les requêtes incontrôlées. Le délai d'expiration des en-têtes protège la phase de connexion au niveau du serveur. Le temps d'exécution PHP est borné par la directive ini max_execution_time propre à PHP (et par la fonction d'exécution set_time_limit()). Une propriété de cette limite diffère de PHP-FPM d'une manière facile à manquer : OxPHP s'appuie sur un build PHP thread-safe (ZTS), où la limite mesure le temps réel écoulé et non le temps CPU. Voir Temps réel écoulé, pas temps CPU.

Fonctionnement

Chaque requête passe par les phases suivantes :

1. Connexion acceptée — le délai d'expiration des en-têtes démarre. OxPHP attend que le client envoie un ensemble complet d'en-têtes HTTP.
2. En-têtes reçus — le délai d'expiration des en-têtes se termine. La requête est distribuée à un worker PHP.
3. PHP traite la requête — le code applicatif s'exécute sous le max_execution_time propre à PHP, armé sous la forme d'un minuteur POSIX par thread. Lorsque la limite est atteinte, la requête est annulée et l'erreur fatale unifiée Request cancelled (timeout) se déclenche. En mode worker, chaque requête conserve sa propre limite, y compris celle que le worker prend en charge alors qu'il en traite déjà d'autres, et une requête suspendue dans une attente au moment où sa limite expire est terminée à sa reprise (voir Mode worker → Échéances des requêtes).
4. Réponse envoyée — sur les connexions keep-alive, le cycle recommence à l'étape 1.

graph TD
  A["TCP connect<br/>(+ TLS handshake if enabled)"] -->|HEADER_TIMEOUT_SECONDS| B["Headers received"]
  B -->|max_execution_time| C["Response sent"]
  C -->|next request, keep-alive| A

Sur les connexions keep-alive, les deux délais d'expiration s'appliquent indépendamment à chaque requête de la connexion.

Le délai d'expiration des en-têtes protège contre les attaques de type slowloris, où un client envoie les en-têtes octet par octet pour maintenir les connexions ouvertes indéfiniment.

La gestion du temps d'exécution PHP est entièrement déléguée à PHP. Lorsque max_execution_time est dépassé, le mécanisme d'annulation unifié d'OxPHP :

• Définit connection_status() & PHP_CONNECTION_TIMEOUT pour que le code utilisateur puisse détecter la cause.
• Exécute tous les callbacks register_shutdown_function(), exactement comme le fait PHP-FPM.
• Renvoie un HTTP 504 Gateway Timeout avec le message Request cancelled (timeout) inscrit dans le journal des erreurs.

Temps réel écoulé, pas temps CPU

max_execution_time mesure depuis combien de temps la requête est en vie, et non la quantité de CPU qu'elle a consommée. Chaque seconde passée à attendre compte : une requête de base de données lente, un appel HTTP vers un autre service, un fread() bloquant sur un socket, un sleep().

C'est une différence avec PHP-FPM, et elle tient au build PHP plutôt qu'à OxPHP. Un build thread-safe (ZTS), qu'OxPHP exige parce qu'il exécute de nombreux interpréteurs PHP comme threads d'un même processus, arme la limite sous la forme d'un minuteur POSIX par thread sur une horloge monotone. Un build non thread-safe, celui qu'exécute PHP-FPM, l'arme avec setitimer(ITIMER_PROF), un minuteur qui n'avance que lorsque le processus est sur le CPU. C'est de là que vient la règle empirique bien connue selon laquelle « l'attente de la base de données ne compte pas dans max_execution_time ». Elle vaut pour PHP-FPM, pas ici.

La conséquence apparaît lors de la migration d'une application existante :

Codes de statut d'annulation

OxPHP annule une requête pour plusieurs raisons distinctes. Chacune correspond à un statut transmis sur le réseau qui reflète la condition réelle plutôt qu'un 500 générique :

Ce sont les trois seules causes d'annulation. Une requête que le superviseur observe au-delà de son seuil est signalée via oxphp_worker_stuck_total et oxphp_worker_long_running_total et laissée en cours d'exécution ; le serveur ne l'annule jamais.

Si votre ERROR_PAGES_DIR ne fournit qu'un 500.html, ajoutez 504.html, 503.html et (facultativement) 499.html pour garder des pages stylisées cohérentes pour toutes les causes d'annulation.

Configuration

Le temps d'exécution PHP se configure via php.ini, et non via les variables d'environnement d'OxPHP :

Ou par script à l'exécution :

Valeurs recommandées

Ajustez ces valeurs en fonction des caractéristiques de votre application. Pour les endpoints SSE, appelez set_time_limit(0) en tête du script de streaming plutôt que de désactiver max_execution_time globalement.

Dépannage

Exemple Docker

Avec php.ini contenant :

Bonnes pratiques

• Ne définissez jamais max_execution_time = 0 globalement en production sauf si vous disposez d'endpoints SSE ou de long-polling qui nécessitent des connexions indéfinies. Préférez set_time_limit(0) par script.
• Utilisez des limites plus courtes pour les serveurs d'API. Les API ont des temps de réponse prévisibles. Un max_execution_time de 30 secondes détecte rapidement les requêtes bloquées sans affecter le trafic normal. Dimensionnez-le en fonction de votre dépendance en aval la plus lente plutôt que du travail CPU effectué par le script, car le temps passé à attendre compte.
• Combinez avec la limitation de débit. Les délais d'expiration protègent les requêtes individuelles ; la limitation de débit protège contre un volume élevé de requêtes. Ensemble, elles couvrent aussi bien les schémas d'attaque lents que rapides.

Prompts pour votre agent

Ces prompts supposent un agent connecté au serveur MCP de la documentation OxPHP — il lira lui-même les pages dont il a besoin.

Voir aussi

• Limitation de débit — limitation du débit de requêtes par IP
• Server-Sent Events (SSE) — conseils sur la désactivation des délais d'expiration pour les endpoints de streaming
• Référence de configuration — référence complète des variables d'environnement