php frameworks
1.0.0
Middleware ist ein allgemeiner Begriff für Software, der dazu dient, separate, oft komplexe und bereits vorhandene Programme zusammenzufassen. Einige Softwarekomponenten, die häufig mit Middleware verbunden sind, umfassen Unternehmensanwendungen und Webdienste.
Ref:
* 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
Was ist Middleware?
Middleware ist Code, der zwischen der Anfrage und der Antwort besteht und die eingehende Anforderung annehmen, darauf basieren und die Antwort entweder abschließen oder die Delegation an die nächste Middleware in der Warteschlange übergeben.
https://github.com/zendframework/zend-stratigility/blob/master/doc/book/middleware.md
HTTP Middleware bietet einen bequemen Mechanismus für die Filterung von HTTP -Anforderungen, die in Ihre Anwendung eintreten. Beispielsweise enthält Laravel eine Middleware, die überprüft, dass der Benutzer Ihrer Anwendung authentifiziert ist. Wenn der Benutzer nicht authentifiziert ist, leitet die Middleware den Benutzer zum Anmeldebildschirm um. Wenn der Benutzer jedoch authentifiziert ist, erlaubt die Middleware die Anfrage, weiter in die Anwendung fortzufahren.
http://laravel.com/docs/master/middleware
Mit Silex können Sie Code ausführen, das das Standard -Silex -Verhalten in verschiedenen Phasen während der Behandlung einer Anfrage durch Middlewares ändert:
http://silex.sensiolabs.org/doc/middlewares.html
Der Zweck von Middleware besteht darin, die Anwendungsumgebung, die Anfrage und die Antwort vor und/oder nach dem Aufrufen der schlanken Anwendung zu überprüfen, zu analysieren oder zu ändern.
http://docs.slimframework.com/middleware/overview/
Alle HTTP -Nachrichten bestehen aus der verwendeten HTTP -Protokollversion, den Headern und einem Nachrichtenkörper. Eine Anfrage erstellt in der Nachricht, um die HTTP -Methode zu enthalten, die zur Erstellung der Anforderung verwendet wird, und die URI, für die die Anfrage gestellt wird. Eine Antwort enthält den HTTP -Statuscode und den Vernunftdruck.
...
Egal, ob Sie ein Programmierer sind oder nicht, Sie haben es überall im Web gesehen. In diesem Moment zeigt Ihre Browser -Adressleiste etwas, das mit "http: //" beginnt. Sogar Ihr erstes Hello World -Skript hat HTTP -Header gesendet, ohne dass Sie es merkten. In diesem Artikel erfahren wir die Grundlagen der HTTP -Headers und darüber, wie wir sie in unseren Webanwendungen verwenden können.
Die HTTP -Antwort, die ein Server an einen Client zurücksendet, enthält Header, die den Inhaltstyp im Körper der Antwort identifizieren, den Server, der die Antwort gesendet hat, wie viele Bytes im Körper sind, wenn die Antwort gesendet wurde, usw. PHP und Apache kümmern sich normalerweise um die Header für Sie und identifizieren Sie das Dokument als HTML , berechnen die Länge des HTML -Page und so weiter. Die meisten Webanwendungen müssen selbst keine Header selbst festlegen. Wenn Sie jedoch etwas zurücksenden möchten, das nicht HTML ist, die Ablaufzeit für eine Seite festlegen, den Browser des Clients umleiten oder einen bestimmten HTTP -Fehler generieren, müssen Sie die Header () -Funktion verwenden.
*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 hat keine integrierte Unterstützung für HTTP-Nachrichten.
...
PHP -Streams sind die bequemste und allgegenwärtigste Methode, um HTTP -Anforderungen zu senden, stellen jedoch eine Reihe von Einschränkungen in Bezug auf die ordnungsgemäße Konfiguration der SSL -Unterstützung und bieten eine umständliche Schnittstelle über das Einstellen von Dingen wie Header. Curl bietet eine vollständige und erweiterte Feature-Set, da es sich jedoch nicht um eine Standardverlängerung handelt, häufig nicht vorhanden. Die HTTP -Erweiterung leidet unter dem gleichen Problem wie Curl sowie die Tatsache, dass sie traditionell weitaus weniger Beispiele für die Nutzung hatte.
Die meisten modernen HTTP -Client -Bibliotheken tendieren dazu, die Implementierung abstrahieren, um sicherzustellen, dass sie an jeder Umgebung arbeiten können, in der sie ausgeführt werden, und über die oben genannten Ebenen hinweg.
Anmerkungen:
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 verwendet Server -APIs (SAPI), um eingehende HTTP -Anforderungen zu interpretieren, Marschalleingaben und die Handhabung an Skripte weiterzugeben. Das ursprüngliche SAPI -Design spiegelte die gemeinsame Gateway -Schnittstelle wider, die Daten anfordern und sie in Umgebungsvariablen drückte, bevor die Delegation an ein Skript weitergegeben wurde. Das Skript würde dann aus den Umgebungsvariablen ziehen, um die Anforderung zu verarbeiten und eine Antwort zurückzugeben.
Das SAPI-Design von PHP Zusammenfassung gemeinsame Eingabestellungen wie Cookies, Abfragestöne und URL-kodierte Post-Inhalte über Superglobals ($ _cookie, $ _get und $ _post) bieten Webentwicklern eine Schicht von Komfort.
...
Die direkte Verwendung von Superglobals hat eine Reihe von Bedenken. Erstens sind diese veränderlich, was es Bibliotheken und Code ermöglicht, die Werte zu ändern und so den Zustand für die Anwendung zu ändern. Darüber hinaus erschweren Superglobals Einheiten und Integrationstests schwierig und spröde, was zu einer Verschlechterung der Codequalität führt.
...
Wenn es um serverseitige Antworten geht, wird PHP schließlich auf seine eigene Art und Weise gerichtet: Alle Inhalte, die vor einem Anruf bei Header () emittiert werden, führt dazu, dass dieser Anruf zu einem No-op wird; Abhängig von den Einstellungen zur Fehlerberichterstattung können häufig Header und/oder Antwortstatus nicht korrekt gesendet werden. Eine Möglichkeit, dies zu umgehen, besteht darin, die Ausgangspufferfunktionen von PHP zu verwenden. Die Verschachtelung von Ausgangspuffern kann jedoch problematisch und schwer zu debuggen werden. Frameworks und Anwendungen neigen daher dazu, Antwortabstraktionen für aggregierte Header und Inhalte zu erzeugen, die gleichzeitig emittiert werden können - und diese Abstraktionen sind häufig nicht kompatibel.
Ref: http://www.php-fig.org/psr/psr-7/meta/
Sie könnten Superglobals -Variablen verwenden (als $ _get und $ _post), aber es handelt sich um einen globalen Veränderungszustand. Zusammen mit dieser Einheit und Integrationstests Ihres Codes wird schwierig.
Aus diesen Gründen haben viele PHP -Frameworks beschlossen, eine Abstaction zu implementieren, um HTTP -Nachrichten darzustellen (siehe zum Beispiel Symfony Httpfoundation oder Zend http).
Dies führte zu einer Situation, in der eine Anwendung auf einer bestimmten Implementierung von HTTP -Nachrichten basierte, so dass sie in Projekten, die mit anderen Frameworks erstellt wurden, kaum verwendet werden konnte.
Aus diesem Grund hilft eine gemeinsame Reihe von Schnittstellen die abstrakten HTTP -Nachrichten und arbeiten mit ihnen auf agnostische Weise mit ihnen zusammen.
Ref: http://stackoverflow.com/questions/32805681/php-why-http-message-implementations
HTTP wird verwendet, um Ressourcen zu übertragen, nicht nur zu Dateien. Eine Ressource ist ein Teil von Informationen, die durch eine URL identifiziert werden können (es ist der R in der URL). Die häufigste Art von Ressource ist eine Datei, aber eine Ressource kann auch ein dynamisch erzeugter Abfrageergebnis sein, die Ausgabe eines CGI-Skripts, ein Dokument, das in mehreren Sprachen verfügbar ist oder etwas anderes.
Ref:
* http://www.w3schools.com/tags/ref_httpmessages.asp
* https://www.jmarshall.com/easy/http/
