Est $_SERVER['REQUEST_SCHEME'] fiable?

J'ai récemment été la recherche d'un moyen de déterminer correctement le protocole, en vertu de laquelle la demande d'url a été fourni au serveur.

J'ai regardé à travers parse_url() et si $_SERVER variable superglobale, et trouvé ceci:

<?php
header('Content-Type: text/plain');

print_r($_SERVER);
?>

De sortie:

[REQUEST_SCHEME] => http

Cependant, j'ai été incapable de le trouver sur php.net ou Google. Bien, j'ai été en mesure de trouver ce question. Q#1: Si $_SERVER['REQUEST_SCHEME'] n'était pas documentée, alors il est probablement peu fiables, ou il peut être digne de confiance?

Je suis en utilisant VC9 PHP 5.4.14 TS sous windows pour le développement. Mais ma production est sous ubuntu. Q#2: Est cette propriété également disponibles sous ubuntu linux aussi?

InformationsquelleAutor BlitZ | 2013-08-02

php url-parsing

33

Il est difficile de prouver qu'il est fiable, mais il est facile de prouver qu'il n'est pas fiable (si seulement je pouvais fournir un cas qu'il ne fonctionne pas). Et je peux prouver que c'est pas fiable car il ne fonctionne pas avec IIS 7.0 + PHP 5.3
- +1, pour nice, réponse logique.
- Merci. Ma production avec PHP 5.4.17 ne montrent pas non plus.
- Zend Server CE sur Windows n'est pas non plus!
- Juste pour informer google: il est également manquant sur lighttpd avec PHP 5.5.9.
- Il ne fonctionne pas avec Apache 2.2, dans son "défaut" de configuration.
- aussi ne fonctionne pas sur Caddyserver.
- et ne semble pas être possible de mettre en https quand derrière un proxy inverse (avec apache 2.4 comme backend)
InformationsquelleAutor invisal
51

La REQUEST_SCHEME variable d'environnement est documenté sur le Apache mod_rewrite page. Cependant, il n'est pas devenu disponible jusqu'Apache 2.4.

Je n'ai qu'Apache 2.2 et j'ai donc créé une variable d'environnement. J'ai ajouté les suivantes au début de ma .fichier htaccess.
```
RewriteEngine on

# Set REQUEST_SCHEME (standard environment variable in Apache 2.4)
RewriteCond %{HTTPS} off
RewriteRule .* - [E=REQUEST_SCHEME:http]

RewriteCond %{HTTPS} on
RewriteRule .* - [E=REQUEST_SCHEME:https]
```
Maintenant je peux utiliser
- %{ENV:REQUEST_SCHEME} dans d'autres réécrire les conditions et les règles
- $_SERVER['REQUEST_SCHEME'] dans mon code PHP
Je n'ai pas à le faire très salissant conditionnelle vérifie partout, et mon code PHP est compatible. Lors de la configuration d'Apache est mis à jour, je peux changer mon .fichier htaccess.

Je ne sais pas comment vous pouvez l'appliquer à un environnement Windows. Ce n'est probablement pas une bonne solution pour la distribution de code, mais il fonctionne bien pour mes besoins.
- Encore, merci bien. Il est bon de savoir d'où il vient.
InformationsquelleAutor toxalot
8

Que cette variable n'est pas disponible dans toutes les versions de serveur, il n'est pas fiable, le test il.
Au lieu de cela, vous pouvez modifier votre code PHP pour tester deux des serveurs de plus les variables d'environnement, qui peuvent également indiquer que le https est utilisé, comme ci-dessous:
```
if ( (! empty($_SERVER['REQUEST_SCHEME']) && $_SERVER['REQUEST_SCHEME'] == 'https') ||
     (! empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ||
     (! empty($_SERVER['SERVER_PORT']) && $_SERVER['SERVER_PORT'] == '443') ) {
    $server_request_scheme = 'https';
} else {
    $server_request_scheme = 'http';
}
```
Comme le fait observer toxalot, REQUEST_SCHEME est un natif de la variable serveur web Apache depuis sa version 2.4. Apache 2.2 ne l'a pas (voir Apache 2.2 les variables de serveur) et Microsoft IIs 8.5 ne l'ont pas, soit (voir IIS 8.5 les Variables de Serveur). Naturellement, si une variable n'est pas définie par le serveur, PHP va pas les inclure dans son tableau global $_SERVER.

Heureusement, pour la compatibilité avec les codes basés exclusivement sur REQUEST_SCHEME de vérification, vous pouvez créer cette variable dans Apache 2.2 montage tous votre hôte, des fichiers de configuration (httpd.conf, ssl.conf, 000-default.conf, vhosts.conf), en ajoutant les lignes suivantes:
```
# FOR HOSTS LISTENING AT PORT 80
SetEnvIf Request_Protocol ^HTTP/ REQUEST_SCHEME=http

# FOR HOSTS LISTENING AT PORT 443
SetEnvIf Request_Protocol ^HTTP/ REQUEST_SCHEME=https
```
Le code ci-dessus suppose que l'utilisation d'un serveur virtuel pour chaque protocole (une des meilleures pratiques dans Apache - voir cette et que).
- Cela ne semble pas une bonne idée d'assumer $server_request_scheme = 'http' lorsque le REQUEST_SCHEME variable d'environnement n'est pas définie. En outre, pour la SetEnvIf Request_Protocol, cela ne fonctionne pas sur les serveurs virtuels à l'écoute sur les deux ports.
- Salut @xhienne. Sur le code PHP: l'idée est de ne pas forcer la définition d'une variable qui existe naturellement dans un serveur web: au lieu de cela, le but est ici de résoudre un problème qui peut survenir dans un serveur où cette variable d'environnement n'existe pas! Dans ce cas, vous avez défini un schéma de requête, mais le serveur n'a pas l'informer de vous "explicitement" (je veux dire, avec précision des chaînes en tant que "http" ou "https"). Le code, par conséquent, n'est qu'un traducteur, lorsque les informations qui vous veut vient d'une autre variable et sous une forme différente.
- Salut aldemarcalazans. Désolé, je suppose que, en raison de sa longueur, j'ai raté les autres conditions de votre déclaration si et seulement vu un test sur REQUEST_SCHEME. En fait, votre code PHP semble ok. Si vous n'avez pas l'esprit, vous pouvez diviser le long de la condition sur plusieurs lignes. Merci.
- Fait: la condition découpé.
- à l'aide d'Apache/2.4.25 (Debian) et php_fpm derrière un reverse proxy (https qui se passe avant d'atteindre apache) je n'ai pas pu changer REQUEST_SCHEME https - apparaît comme quelque chose d'autre est en l'obligeant retour à http (je peux le voir d'en modifier l'ordre des variables sont affichées dans phpinfo() mais la valeur reste http
- Salut @Antony Gibbs. Dans ce cas, je pense que vous devriez tester une autre variable: la variable $_SERVER['HTTP_X_FORWARDED_PROTO']. Voir developer.mozilla.org/en-US/docs/Web/HTTP/Headers/...
- Salut @aldemarcalazans. Je vous recommande de le tester pour $_SERVER['HTTPS'] == 'on' qui peuvent être définis par proxy_set_header X-Forwarded-SSL $https; (nginx) et SetEnvIf X-Forwarded-SSL on HTTPS=on (apache2) et jamais, jamais utiliser totalement fiable REQUEST_SCHEME
InformationsquelleAutor aldemarcalazans
7

Moi aussi, je n'arrivais pas à trouver une référence à REQUEST_SCHEME, mais si vous êtes à la recherche pour déterminer si une demande a été faite par http: ou https: ensuite, vous pouvez utiliser $_SERVER['HTTPS'], qui est fixé à une valeur non vide si une demande a été faite par https:. Il est documenté sur le PHP du site ici
- Dans certaines conditions, la $_SERvER['HTTPS'] donne de la valeur non vide (off) qui indique que le HTTPS n'a PAS été utilisé. Plus d'infos sur la page liée à la réponse.
- Merci pour la note. Il est très utile.
- isset($_SERVER['HTTPS']) && 'on' === $_SERVER['HTTPS'] semble être le moyen le plus sûr pour déterminer https://
InformationsquelleAutor
5

Dans la nouvelle version de Nginx, définie par défaut fastcgi_param REQUEST_SCHEME $scheme.

InformationsquelleAutor S.A.N
2

L'amélioration de toxalot de suggestion pour les utilisateurs de CloudFlare:
```
RewriteEngine on

RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteRule .* - [E=REQUEST_SCHEME:http]

RewriteCond %{HTTPS} on [OR]
RewriteCond %{HTTP:CF-Visitor} '"scheme":"https"'
RewriteRule .* - [E=REQUEST_SCHEME:https]
```
- Je dois ajouter que cet en-tête est JSON et techniquement, ils pourraient ajouter un espace après les deux points et sortir de la logique de la configuration, mais bien sûr, je comprends que Apache ne permet pas de parser JSON et Cloudflare personnel sont probablement au courant que les gens font chaîne correspond à l'intérieur du JSON.. Plus sur Cloudflare-tête: support.cloudflare.com/hc/en-us/articles/...
InformationsquelleAutor Sinus Mackowaty
2

Cette valeur dépend de votre serveur web. Si vous utilisez nginx (v1.10), dans le fichier /etc/nginx/fastcgi_params vous pouvez le voir, cette lignes suivantes :
```
fastcgi_param  REQUEST_SCHEME     $scheme; 
fastcgi_param  HTTPS              $https if_not_empty;
```
Généralement, ces valeurs par défaut sont suffisantes.
Mais il est possible que cela ne fonctionne pas, vous pouvez la force de ces valeurs dans votre vhost :
```
include fastcgi_params;
fastcgi_param  REQUEST_SCHEME     https; 
fastcgi_param  HTTPS              On;
```
Si vous utilisez Apache, vous pouvez prendre un coup d'oeil toxalot la réponse de

InformationsquelleAutor Arno

Son intéressant de voir comment WordPress résout ce problème avec son is_ssl() fonction qui rend l'utilisation de la variable $_SERVER variable,

function is_ssl() {
    if ( isset( $_SERVER['HTTPS'] ) ) {
        if ( 'on' == strtolower( $_SERVER['HTTPS'] ) ) {
            return true;
        }

        if ( '1' == $_SERVER['HTTPS'] ) {
            return true;
        }
    } elseif ( isset( $_SERVER['SERVER_PORT'] ) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
        return true;
    }
    return false;
}

InformationsquelleAutor Aurovrata

Vous devez vous connecter pour publier un commentaire.