php frameworks
1.0.0
Le middleware est un terme général pour les logiciels qui sert à «coller ensemble» des programmes séparés, souvent complexes et déjà existants. Certains composants logiciels qui sont fréquemment connectés au middleware comprennent les applications d'entreprise et les services Web.
Réf:
* http://searchsoa.techtarget.com/definition/middleware
* http://www.webopedia.com/TERM/M/middleware.html
* http://www.softwareag.com/blog/reality_check/index.php/integration-insights/middleware-for-my-mom-or-kids-guide-to-what-i-do/
* http://www.networkcomputing.com/netdesign/cdmwdef.htm
* https://en.wikipedia.org/wiki/Middleware
Qu'est-ce que le middleware?
Le middleware est un code qui existe entre la demande et la réponse, et qui peut prendre la demande entrante, effectuer des actions en fonction de celle-ci et compléter la réponse ou passer la délégation au middleware suivant dans la file d'attente.
https://github.com/zendframework/zend-stratility/blob/master/doc/book/middleware.md
Le middleware HTTP fournit un mécanisme pratique pour filtrer les demandes HTTP entrant dans votre application. Par exemple, Laravel comprend un middleware qui vérifie que l'utilisateur de votre application est authentifié. Si l'utilisateur n'est pas authentifié, le middleware redirige l'utilisateur vers l'écran de connexion. Cependant, si l'utilisateur est authentifié, le middleware permettra à la demande de procéder davantage dans l'application.
http://laravel.com/docs/master/middleware
Silex vous permet d'exécuter du code, qui modifie le comportement de Silex par défaut, à différentes étapes pendant la gestion d'une demande via Middlewares:
http://silex.sensiolabs.org/doc/middlewares.html
Le but du middleware est d'inspecter, d'analyser ou de modifier l'environnement d'application, la demande et la réponse avant et / ou après l'invoquer l'application SLIM.
http://docs.slimframework.com/middleware/overview/
Tous les messages HTTP sont constitués de la version du protocole HTTP utilisé, des en-têtes et un corps de message. Une demande s'appuie sur le message pour inclure la méthode HTTP utilisée pour faire la demande et l'URI à laquelle la demande est faite. Une réponse comprend le code d'état HTTP et la phrase de raison.
...
Que vous soyez programmeur ou non, vous l'avez vu partout sur le Web. En ce moment, votre barre d'adresse de navigateurs montre quelque chose qui commence par "http: //". Même votre premier script Hello World a envoyé des en-têtes HTTP sans que vous vous en rendions compte. Dans cet article, nous allons en apprendre davantage sur les bases des en-têtes HTTP et comment nous pouvons les utiliser dans nos applications Web.
La réponse qu'un serveur renvoie à un client contient des en-têtes qui identifient le type de contenu dans le corps de la réponse, le serveur qui a envoyé la réponse, combien d'octets sont dans le corps, lorsque la réponse a été envoyée, etc. PHP et Apache prennent normalement soin de la page HTML, et ainsi de suite. La plupart des applications Web n'ont jamais besoin de définir elles-mêmes des en-têtes. Cependant, si vous souhaitez renvoyer quelque chose qui n'est pas HTML, définissez le temps d'expiration pour une page, redirigez le navigateur du client ou générez une erreur HTTP spécifique, vous devrez utiliser la fonction d'en-tête ().
*How to See HTTP Headers*
* Firebug extensions to analyze HTTP headers.
1. Turn in Firebug
2. Click Net
3. Click Headers
Ref:
* http://docstore.mik.ua/orelly/webprog/php/ch07_05.htm
* http://code.tutsplus.com/tutorials/http-headers-for-dummies--net-8039
*Headers already sent: Why does it happen?*
To understand why headers must be sent before output it's necessary to look at a typical HTTP response. PHP scripts mainly generate HTML content, but also pass a set of HTTP/CGI headers to the webserver:
HTTP/1.1 200 OK
Powered-By: PHP/5.3.7
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
<html><head><title>PHP page output page</title></head>
<body><h1>Content</h1> <p>Some more output follows...</p>
and <a href="/"> <img src=internal-icon-delayed> </a>
The page/output always follows the headers. PHP has to pass the headers to the webserver first. It can only do that once. After the double linebreak it can nevermore amend them.
When PHP receives the first output (print, echo, <html>) it will flush all collected headers. Afterwards it can send all the output it wants. But sending further HTTP headers is impossible then.
PHP n'a pas de support intégré pour les messages HTTP.
...
Les flux PHP sont le moyen le plus pratique et le plus omniprésent d'envoyer des demandes HTTP, mais posent un certain nombre de limitations en ce qui concerne la configuration correcte de la prise en charge SSL, et fournir une interface lourde autour de la définition de choses telles que des en-têtes. Curl fournit un ensemble de fonctionnalités complet et élargi, mais, car il ne s'agit pas d'une extension par défaut, n'est souvent pas présent. L'extension HTTP souffre du même problème que Curl, ainsi que le fait qu'elle a traditionnellement eu beaucoup moins d'exemples d'utilisation.
La plupart des bibliothèques clients HTTP modernes ont tendance à résumer la mise en œuvre, pour s'assurer qu'ils peuvent travailler sur n'importe quel environnement sur lequel ils sont exécutés et sur l'une des couches ci-dessus.
Notes:
cURL allows you to connect and communicate to many different types of servers with many different types of protocols.
(http://php.net/manual/en/intro.curl.php)
PHP utilise les API du serveur (SAPI) pour interpréter les demandes HTTP entrantes, les entrées de maréchal et passer la manipulation des scripts. La conception SAPI d'origine reflétait l'interface de passerelle commune, qui maturait les données de demande et la pousserait à des variables d'environnement avant de passer la délégation à un script; Le script tirait ensuite des variables d'environnement afin de traiter la demande et de renvoyer une réponse.
Les résumés de conception SAPI de PHP sont des sources d'entrée communes telles que les cookies, les arguments de chaîne de requête et le contenu du post codé par URL via des superglobals ($ _cookie, $ _get et $ _post, respectivement), offrant une couche de commodité aux développeurs Web.
...
L'utilisation directe des superglobals a un certain nombre de préoccupations. Premièrement, ceux-ci sont mutables, ce qui permet aux bibliothèques et au code de modifier les valeurs, et ainsi modifier l'état de l'application. De plus, les superglobals rendent les tests d'unité et d'intégration difficiles et cassants, conduisant à une dégradation de la qualité du code.
...
Enfin, en ce qui concerne les réponses côté serveur, PHP se fait à sa manière: tout contenu émis avant un appel à en-tête () entraînera cet appel de devenir un no-op; Selon les paramètres de rapport d'erreur, cela peut souvent signifier que les en-têtes et / ou l'état de réponse ne sont pas correctement envoyés. Une façon de contourner cela consiste à utiliser les fonctionnalités de tampon de sortie de PHP, mais la nidification des tampons de sortie peut devenir problématique et difficile à déboguer. Les cadres et les applications ont donc tendance à créer des abstractions de réponse pour les en-têtes d'agrégation et le contenu qui peuvent être émis en même temps - et ces abstractions sont souvent incompatibles.
Ref: http://www.php-fig.org/psr/psr-7/meta/
Vous pouvez utiliser des variables SuperGlobal (comme $ _get et $ _post), mais ce sont un état mutable global. Avec cette unité et les tests d'intégration de votre code deviennent difficiles.
Pour ces raisons, de nombreux cadres PHP ont décidé d'implémenter une abstaction pour représenter les messages HTTP (voir par exemple Symfony httpfoundation ou zend http).
Cela a conduit à une situation où une application était basée sur une implémentation spécifique des messages HTTP, de sorte qu'il était à peine utilisable dans les projets construits à l'aide d'autres cadres.
C'est pourquoi un ensemble commun d'interfaces aide à résumer les messages HTTP et à travailler avec eux d'une manière agnostique de cadre.
Ref: http://stackoverflow.com/questions/32805681/php-why-http-message-implementations
HTTP est utilisé pour transmettre des ressources, pas seulement les fichiers. Une ressource est une partie des informations qui peuvent être identifiées par une URL (c'est la R dans l'URL). Le type de ressource le plus courant est un fichier, mais une ressource peut également être un résultat de requête généré dynamiquement, la sortie d'un script CGI, un document disponible en plusieurs langues ou autre chose.
Réf:
* http://www.w3schools.com/tags/ref_httpmessages.asp
* https://www.jmarshall.com/easy/http/
