Dev Faq
9
votes

Quelle est la fiabilité http_host?

J'ai écrit un script PHP que j'aimerais utiliser sur plusieurs domaines sur le même serveur (pointant vers le même script). Je souhaite ajouter des fonctionnalités au script afin que je puisse savoir quel domaine fonctionne le script avec à tout moment. Http_host peut être utilisé pour trouver le domaine, cependant, j'ai lu que ce n'est pas fiable, en particulier avec des navigateurs plus anciens. Ma compréhension est la plupart des serveurs Apache utilisent des hôtes virtuels qui utilisent la même méthode de toute façon, donc si ce n'est pas un problème avec les fournisseurs d'hébergement, il ne devrait pas être un problème avec mon code.

Quelqu'un peut-il vérifier cela et effacer la confusion?

0 commentaires

5 Réponses :

9
votes

EDIT : Je suis corrigé: l'en-tête d'hôte n'est pas présent dans les demandes HTTP 1.0. Voir la réponse de @ Bruno. Laissant le mien en place à cause des considérations de sécurité

Les seules problèmes avec http_host dont je suis au courant sont des problèmes de sécurité et non de la compatibilité.

Les problèmes de sécurité découlent du fait que http_host est envoyé par l'utilisateur. Si le serveur Web est configuré de manière incorrecte et / ou buggy, les valeurs arbitraires http_host pourraient le faire sur votre site / script (voir par exemple ici pour une discussion détaillée). Votre application doit être préparée pour cela.

Il est bon de ne jamais faire confiance à http_host (par exemple, il peut être une bonne idée de configurer une matrice de valeurs autorisées pour cela avant de le traiter dans votre script PHP): < / p> xxx

6 commentaires

+1 Pour votre réponse aussi, bien que ce ne soit pas à propos de la compatibilité des navigateurs plus âgés, il est définitivement sur la thème "Quelle est la fiabilité http_host?"

@Pekka c'est ce que j'ai l'intention de faire. Cela entraîne également une autre question dans mon esprit, il serait préférable d'autoriser Apache à résoudre ce problème et d'utiliser http_server l'alias du serveur. Le seul problème que j'ai avec cela fait la dynamique hôte.conf.

@andicrook qui fonctionnerait, mais vous devez configurer un Vhost pour chaque nom de domaine concevable. Mais voyant que vous aurez besoin d'introduire tous les noms de domaine dans httpd.conf de toute façon ....

Je devrais pouvoir définir l'hébergement virtuel pour être dynamique ou utiliser des cnames

@andi je dois me corriger, je suis à peu près sûr que est possible en utilisant des caractères génériques. Serverfault.com peut avoir de meilleures réponses sur ce problème spécifique

@Pekka Oui, vous pouvez les utiliser avec Serveralias

10
votes

http_host est pour le < Code> Host: En-tête envoyé par HTTP 1.1 User-Agents lors de la demande. Ceci n'est pas utilisé par les clients HTTP 1.0, il n'apparaîtra donc pas. Cependant, de nos jours, je ne pense pas qu'il y ait encore beaucoup de clients HTTP 1.0.

3 commentaires

Et même la plupart des clients HTTP 1.0 sont étendus à l'aide de ce champ maintenant - seul l'ancien HTTP 1.0 non mis à jour ne le fournit pas.

@Pekka pas une grosse affaire. Un tel client imaginaire n'atteindra pas le plus de sites (nommé hôte virtuel), donc, il est simplement impraticable.

@Col Yeah, c'était ce que je me demandais: comment un tel client peut-il demander une ressource à un serveur multi-Vhost? Cela doit être vraiment vieux. Quoi qu'il en soit, il répond à la question

1
votes

La réponse de Pekka semble plus intéressante, mais il semble que vous souhaitiez savoir quels navigateurs prennent en charge HTTP 1.1 et qui ne font pas. Trouvé ceci sur google: HTTP : //www.1-script.com/forums/browser-support-for-http-1-Article34982--8.htm

une note, à partir de ce thread: "Un navigateur HTTP 1.0 Impossible d'accéder à l'hôte virtuel non par défaut." Cela signifie qu'un navigateur qui ne prend pas en charge HTTP 1.1 ne peut atteindre aucun site Web sur un serveur partagé autant que je sache. Taré de nombreux sites Web sur les hôtes partagés. Aussi sous-domaines pourrait (rien que) soit "détecté" de la même manière, en utilisant le http_host var.

Après avoir lu celles-ci, je ne pense pas vraiment que quiconque utilise un navigateur que le vieux jour d'aujourd'hui, il leur serait impossible de naviguer sur le Web :)

3 commentaires

pensez vous, il y a encore beaucoup de téléphones mobiles qui utilisent http / 1.0

avez-vous une? Je suis curieux s'ils ne peuvent pas accéder à des sous-domaines.

Oui Apache utilise http_host pour la plupart des hôtes virtuels, si son hébergement basé sur IP peut alors utiliser la recherche inverse DNS qui créerait des frais généraux de toute façon

0
votes

C'est ce que j'ai répondu dans un Question similaire :

regarder dans cela moi-même à d'autres fins:

"http / 1.0 est utilisé par des proxies, des clients mobiles, et c'est-à-dire quand configuré pour utiliser un proxy. Donc 1.0 semble toujours rendre compte d'un non- % de trafic sur le Web en général. ... Oui, il y a beaucoup de 1,0 clients là-bas. "

Source (juillet 2009): http://groups.google.com / Groupe / Erlang-Programmation / MSG / 08F6B72D5156EF74

: - (

Je reçois personnellement quelques demandes http / 1.0 sur mes sites avec un http_host manquant: - (

0 commentaires
0
votes

C'est un ancien poste que je trébuche et la solution que j'ai donnée est la suivante:

J'ai créé un fichier JSON (mon code fait une utilisation intensive de ceux que j'appelle des jetons) pour devenir la source unique de vérité et être Ouvert en même temps pour les modifications de qui sait quelles nouvelles choses émergeront dans une application / cadre: p> xxx pré>

maintenant, tout ce que vous avez à faire est de consulter vos entrées dans une Fichier: P> 

// find php executable
cent$ whereis php
php: /usr/bin/php7.0 /usr/bin/php /usr/lib/php /etc/php /usr/include/php ...

// start interactive shell
cent$ /usr/bin/php7.0 -a

php > $json = file_get_contents('accounttoken.json');
php > $json = json_decode($json, true);
php > echo('Your domain is: ' . $json['site']['domain']);
php > echo('The site url is: ' . $json['site']['protocol'] . $json['site']['domain']);
php > quit

1 commentaires

déjà prouvé correct: cookie.domain dans un autre fichier JSON doit être défini sur localhost pendant Site.Domain dans ce fichier doit être défini dans mon Exemple Lors de la redirection de localhost sur Nagrok Server et de l'authentification des tests!

Articles qui pourrait vous intéresser :

Pourquoi est-ce que j'obtiens une erreur laravel lors de la création d'un nouveau projet?
Select2 ne s'affiche pas correctement dans le mode bootstrap
Laravel Echo n'écoute pas
La validation de la demande de formulaire ne fonctionne pas. Il charge juste la page d'accueil dans Postman