Les liens de la semaine – Édition #106

Développement

.NET

Technologie

Web

Science et autres

Advertisements

Les liens de la semaine – Édition #103

Développement

.NET

ASP.NET vNext

Technologie

Web

  • Votre vie sur terre. Un exercice de visualisation intéressant sur les événements survenus durant votre vie de la part de la BBC.

Science et autres

Pour une redirection temporaire, faut-il utiliser le code HTTP 302 ou 307?

Il semble que, depuis que le web est ce qu’il est, la façon officielle de faire une redirection temporaire est d’envoyer au navigateur web le code HTTP 302. Un collègue m’est arrivé avec cette remarque l’autre jour. Pourquoi utiliser le code HTTP 302 pour faire une redirection temporaire alors que le code 307 Temporary Redirect existe?

Une mise en contexte s’impose

La première, la plus connue, est la redirection 301. Cette redirection, permanente, permet d’indiquer que la ressource demandée sera dorénavant accessible à une nouvelle adresse. La deuxième est la 302. Cette redirection est un utilitaire lorsqu’il est temps de déplacer un visiteur sur une autre page sans affecter l’indexation d’une page.

Cette affirmation est vraie. En particulier pour le monde du SEO où ces deux codes HTTP font foi de tout lorsqu’il est temps d’indexer une page web.

Alors donc, pourquoi parlons-nous encore du code HTTP 302 pour les redirections temporaires alors qu’il existe un code ayant une définition plus claire et pertinente? La raison est simple. Le code HTTP 307 appartient à la révision 1.1 du protocole HTTP. Cela veut dire qu’aux débuts d’internet, il y avait uniquement le code 302 et c’est ainsi que nous avons pris l’habitude de l’utiliser.

Comme HTTP/1.1 est un ajout à la version 1.0 de la spécification du protocole, les deux codes cohabitent parfaitement. D’autant plus que, le protocole HTTP étant ce qu’il est, il revient au client web de spécifier quelle version du protocole HTTP il préfère communiquer avec le serveur. Certains clients HTTP vont indiquer une préférence pour HTTP/1.0, malgré ses limitations, afin de bénéficier de la souplesse du protocole sur le nombre de connexions simultanées à un serveur.

Comment faire une redirection 307 avec ASP.NET MVC 5

Alors donc, si la rétrocompatibilité absolue envers les clients HTTP n’est pas votre genre, sachez qu’il est possible de faire une redirection HTTP 307 avec ASP.NET MVC sans problèmes.

De plus, considérez ceci. Les chances que vous aillez à supporter un client exigeant uniquement HTTP/1.0 sont assez minces. En particulier si vous faites du développement web comme moi. Pensez-y. Les sites que j’ai récemment développés sont uniquement compatibles avec Internet Explorer 9 et plus. Pas de problèmes de ce côté, n’est-ce pas?

Ce code va produire les requêtes HTTP suivantes:

fiddler-307

 

Une dernière pensée à ce sujet

À cette époque-ci, il est de moins en moins nécessaire de connaitre par cœur tous les codes HTTP pour arriver à faire du développement web. Toutefois, il est vraiment important de connaitre certains essentiels. Notamment comment les codes sont regroupés.

Est-ce que vous vous demandez quel est le rapport avec les redirections HTTP? Il y en a très peu, en fait. C’est juste que j’ai trouvé le tweet assez drôle et tant qu’à être dans le sujet du protocole HTTP, je n’ai pas pu m’empêcher!

Les liens de la semaine – Édition #101

Développement

.NET

ASP.NET vNext

Technologie

Web

 Science et autres

Une brève explication du concept de la restriction d’origine d’exécution avec JavaScript (Same-Origin et CORS)

Internet est composé d’un drôle d’amalgame de concepts datant des années 1990 et de technologies novatrices qui sont créées à même ces piliers. Depuis sa création, le protocole HTTP, dans ses grandes lignes, est resté semblable.

Le protocole HTTP est à la base de toutes les requêtes que vous faites avec votre navigateur. C’est ce qui permet de transférer le texte entre un serveur web et votre navigateur. Je ne vous apprends rien de nouveau là dessus.

Initialement, une page web était un document assez statique composé de texte, d’images et quelques feuilles de styles sinon très peu. La nécessité d’avoir du dynamisme sur une page web s’est fait sentir très tôt dans l’histoire du web. C’est ainsi que JavaScript a été créé par Netscape en 1995.

Same-Origin

Dès sa création, des mécanismes de sécurité ont dû être mis en place pour limiter la portée d’exécution de JavaScript. C’est ainsi que la politique d’origine d’exécution (Same-Origin) a été instaurée.

Le concept en question est très simple à comprendre. Un script JavaScript doit accéder aux requêtes du domaine d’où il provient. La principale raison de ceci est une question de sécurité.

Groso modo, vous ne pouvez pas faire ce genre de requêtes.

cors

Imaginez si n’importe quel script provenant de l’externe serait en mesure d’accéder à vos cookies d’authentification à n’importe quel moment sans votre autorisation? Trop facile!

Une méthode de contournement

Avez-vous déjà entendu parler du CORS? Ou même de la technique utilisant document.domain?

Il s’agit de deux techniques vous permettant de contourner, avec le consentement de votre vis à vis côté serveur, la restriction de l’origine d’exécution JavaScript. Parce qu’avec toute règle, ça prend une exception pour la confirmer. N’est-ce pas?

document.domain

Cette technique repose sur l’assignation à la propriété document.domain du nom de domaine vers lequel vous tentez d’utiliser la ressource. Toutefois, cette technique implique que les deux ressources web doivent utiliser une valeur commune pour cette propriété.

De plus, certaines règles sont à respecter en lien avec le nom de domaine utilisé et ce qui peut être assigné à document.domain. Les règles sont bien résumées ici.

Personnellement, cette technique est à utiliser avec précaution, car elle est sujette à changements d’interprétations par les différents navigateurs. La meilleure technique à utiliser est CORS.

CORS

Le CORS est en fait, comme vous vous en doutez bien, un acronyme pour Cross-Origin Resource Sharing. Il s’agit d’un en-tête de réponse HTTP qui spécifie les domaines pouvant faire appel à une ressource HTTP.

Cela fait en sorte que la politique d’accès aux ressources est spécifiée par le serveur web qui héberge. L’entête HTTP en question prend la forme suivante :

HTTP/1.1 200 OK
Date: Thu, 18 Feb 2014 10:43:27 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/json

Dans le cas mentionné, l’entête autorise l’accès aux ressources du site à toutes requêtes de type intersites. Si l’entête est manquant, vous ne serez pas autorisé à faire une requête comme j’ai illustré plus haut.

Sources