Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

IIS – Comment connaitre le serveur ayant répondu à la requête lors de l’utilisation d’un Load-Balancer

Il est de plus en plus fréquent qu’un site web utilise plus d’un serveur Web pour fonctionner. Cela se fait généralement grâce à un load-balancer, un équipement qui se met devant tous les serveurs web et qui va distribuer les requêtes vers les différents serveurs.

Parfois, il est intéressant de savoir quel serveur nous a répondu, c’est surtout utile en debug quand juste un serveur ne fonctionne pas correctement.

Pour ce faire, la solution la plus simple est d’utiliser les en-têtes HTTP. Un en-tête HTTP est une ligne que peut ajouter le serveur web au tout début de la réponse, les en-têtes sont couramment utilisés pour définir le cache client, les cookies, etc.

Au niveau de IIS, il est possible de définir des entêtes HTTP soit au niveau d’un site web, soit au niveau du serveur. Je vous conseille de rajouter cet en-tête au niveau du serveur, ainsi tous les sites en profiteront.

Pour cela, lancez la console d'administration IIS, au niveau du serveur, chercher la fonctionnalité “HTTP Response Header

image

Puis ajouter une entrée :

image

Le nom de l’entête n’a pas d’importance, il ne s’agit que d’une information qui sera utilisé lors du debug. Cependant, certains nom sont réservés, la liste de ces en-têtes sont définies ici : IANA Permanent Message Header Field Names et IANA Provisional Message Header Field Names. De plus, éviter de mettre des informations confidentielles.

La plupart des outils de debug web permettent de lires les en-têtes HTTP : Fiddler, Firebug, Internet Explorer, etc. La capture ci-dessous montre les entêtes HTTP avec Internet Explorer.

image

Pour en savoir plus sur les en-têtes HTTP : List of HTTP header fields [Wikipedia] 

Et vous, utilisez-vous couramment cette technique ?

Posted: samedi 12 novembre 2011 14:50 par cyril
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

emmanuel.roulle a dit :

Attention toutefois à ne pas mettre d'informations (nom de serveur ou IP par exemple) qui pourraient servir de base à une attaque.

# novembre 14, 2011 11:27

realpasso a dit :

Je trouve préférable que le nom du serveur figure dans la page générée du style  car l'info persiste même lorsqu'elle est cachée localement ou par un (reverse) proxy. Cela permet également de vérifier rapidement que la mise en cache fonctionne.

Sinon, je trouve plus facile d'ajouter l'entête depuis la config (customheaders) ou le code (ifdef debug response.headers.add...) que de devoir faire une demande à l'admin. Enfin, tout ce qui est hors spec doit être préfixé ("X-SRV" vs "SRV").

# novembre 14, 2011 14:31

cyril a dit :

"Enfin, tout ce qui est hors spec doit être préfixé ("X-SRV" vs "SRV")."

Je me suis posé la question et je n'ai trouvé aucune information du genre dans les RFC ou autres documents "officiel". Je n'ai pas cherché très longtemps, j'ai peut être loupé l'info :-)

As tu un lien qui montre ca ?

# novembre 14, 2011 14:54

realpasso a dit :

HTTP 1.1 (RFC 2616)

4.1 Message Types

...

Request (section 5) and Response (section 6) messages use the generic message format of RFC 822

4.2 Message Headers

...

HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822

RFC 822

To  provide  user-defined fields  with  a  measure  of  safety,  in name selection, such extension-fields will never have names  that  begin  with  the         string "X-".

The prefatory string "X-" will never  be  used  in  the names of Extension-fields.

# novembre 14, 2011 16:51
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- « Naviguer vers le haut » dans une librairie SharePoint par Blog de Jérémy Jeanson le 10-07-2014, 13:21

- PowerShell: Comment mixer NAGIOS et PowerShell pour le monitoring applicatif par Blog Technique de Romelard Fabrice le 10-07-2014, 11:43

- ReBUILD 2014 : les présentations par Le blog de Patrick [MVP Office 365] le 10-06-2014, 09:15

- II6 Management Compatibility présente dans Windows Server Technical Preview avec IIS8 par Blog de Jérémy Jeanson le 10-05-2014, 17:37

- Soft Restart sur Windows Server Technical Preview par Blog de Jérémy Jeanson le 10-03-2014, 19:43

- Non, le certificat public du CA n’est pas un certificat client !!! par Blog de Jérémy Jeanson le 10-03-2014, 00:08

- Windows Server Technical Preview disponible via MSDN par Blog de Jérémy Jeanson le 10-02-2014, 19:05

- Focus Sauvegardes SharePoint par Le blog de Patrick [MVP Office 365] le 10-02-2014, 13:11

- Technofolies, votre évènement numérique de l'année par Le Blog (Vert) d'Arnaud JUND le 09-26-2014, 18:40

- Xamarin : From Zero to Hero par Fathi Bellahcene le 09-24-2014, 17:35