php frameworks
1.0.0
미들웨어는 별도의 복잡하고 이미 존재하는 프로그램을 "함께 붙잡는"소프트웨어의 일반적인 용어입니다. 미들웨어와 자주 연결된 일부 소프트웨어 구성 요소에는 엔터프라이즈 애플리케이션 및 웹 서비스가 포함됩니다.
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
미들웨어 란 무엇입니까?
미들웨어는 요청과 응답 사이에 존재하며 들어오는 요청을 취하고이를 기반으로 작업을 수행하며 대기열의 다음 미들웨어로 대표단을 완료하거나 통과 할 수있는 코드입니다.
https://github.com/zendframework/zend-stratigility/blob/master/doc/book/middleware.md
HTTP 미들웨어는 응용 프로그램을 입력하는 HTTP 요청을 필터링하기위한 편리한 메커니즘을 제공합니다. 예를 들어, Laravel에는 응용 프로그램 사용자가 인증 된 것으로 확인하는 미들웨어가 포함되어 있습니다. 사용자가 인증되지 않으면 미들웨어는 사용자를 로그인 화면으로 리디렉션합니다. 그러나 사용자가 인증 된 경우 미들웨어는 요청이 응용 프로그램으로 더 진행할 수 있도록합니다.
http://laravel.com/docs/master/middleware
Silex는 중간 전쟁을 통한 요청을 처리하는 동안 다른 단계에서 기본 Silex 동작을 변경하는 코드를 실행할 수 있습니다.
http://silex.sensiolabs.org/doc/middlewares.html
미들웨어의 목적은 슬림 한 애플리케이션이 호출 된 후 및/또는/또는 후에 응용 프로그램 환경, 요청 및 응답을 검사, 분석 또는 수정하는 것입니다.
http://docs.slimframework.com/middleware/overview/
모든 HTTP 메시지는 사용중인 HTTP 프로토콜 버전, 헤더 및 메시지 본문으로 구성됩니다. 요청은 요청을 작성하는 데 사용되는 HTTP 메소드와 요청이 이루어지는 URI를 포함하도록 메시지를 작성합니다. 응답에는 HTTP 상태 코드 및 이유 문구가 포함됩니다.
...
당신이 프로그래머이든 아니든, 당신은 웹의 모든 곳에서 그것을 보았습니다. 이 순간 브라우저 주소 막대는 "http : //"로 시작하는 것을 보여줍니다. 첫 번째 Hello World 스크립트조차도 깨닫지 않고 HTTP 헤더를 보냈습니다. 이 기사에서는 HTTP 헤더의 기본 사항과 웹 애플리케이션에서이를 사용할 수있는 방법에 대해 배울 것입니다.
서버가 클라이언트로 다시 전송하는 HTTP 응답에는 응답 본문의 콘텐츠 유형 을 식별하는 헤더가 포함되어 있습니다. 응답 본문, 응답을 보낸 서버, 신체에 몇 개의 바이트 수, 응답이 전송 될 때의 바이트 수 등. 대부분의 웹 응용 프로그램은 헤더 자체를 설정할 필요가 없습니다. 그러나 HTML이 아닌 것을 다시 보내려면 페이지의 만료 시간을 설정하거나 클라이언트 브라우저를 리디렉션하거나 특정 HTTP 오류를 생성하려면 Header () 함수를 사용해야합니다.
*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에는 HTTP 메시지를 지원하지 않습니다.
...
PHP 스트림은 HTTP 요청을 보내는 가장 편리하고 유비쿼터스 방법이지만 SSL 지원을 올바르게 구성하는 것과 관련하여 여러 제한 사항을 제시하고 헤더와 같은 물건을 설정하는 데있어 번거로운 인터페이스를 제공합니다. Curl은 완전하고 확장 된 기능 세트를 제공하지만 기본 확장이 아니기 때문에 종종 존재하지 않습니다. HTTP 확장은 CURL과 동일한 문제와 전통적으로 사용의 예가 훨씬 적다는 사실을 겪고 있습니다.
대부분의 최신 HTTP 클라이언트 라이브러리는 구현을 추상화하여 실행되는 환경과 위의 계층에서 작업 할 수 있도록 구현을 추상화하는 경향이 있습니다.
참고 :
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는 서버 API (SAPI)를 사용하여 들어오는 HTTP 요청, 마샬 입력 및 스크립트로 처리를 전달합니다. 원래 SAPI 디자인은 공통 게이트웨이 인터페이스를 반영하여 대표단을 스크립트로 전달하기 전에 데이터를 요청하고 환경 변수로 밀어 넣습니다. 그런 다음 스크립트는 요청을 처리하고 응답을 반환하기 위해 환경 변수에서 가져옵니다.
PHP의 SAPI 디자인은 쿠키, 쿼리 문자열 인수 및 SuperGlobals (각각 $ _cookie, $ _get 및 $ _post)를 통해 쿠키, 쿼리 문자열 인수 및 URL 인코딩 포스트 컨텐츠와 같은 일반적인 입력 소스를 사용하여 웹 개발자에게 편의 계층을 제공합니다.
...
Superglobals의 직접 사용에는 여러 가지 문제가 있습니다. 먼저, 이들은 변이 가능하므로 라이브러리와 코드가 값을 변경하여 응용 프로그램의 상태를 변경할 수 있습니다. 또한 SuperGlobals는 단위 및 통합 테스트를 어렵고 부서지기 쉽게 만들어 코드 품질 저하로 이어집니다.
...
마지막으로, 서버 측 응답과 관련하여 PHP는 자체 방식으로 얻습니다. Header ()로 호출되기 전에 방출되는 모든 컨텐츠는 해당 통화가 No-OP가됩니다. 오류보고 설정에 따라, 이는 종종 헤더 및/또는 응답 상태가 올바르게 전송되지 않는다는 것을 의미 할 수 있습니다. 이를 해결하는 한 가지 방법은 PHP의 출력 버퍼링 기능을 사용하는 것이지만 출력 버퍼의 중첩은 문제가되고 디버깅하기가 어려워 질 수 있습니다. 따라서 프레임 워크 및 응용 프로그램은 한 번에 방출 될 수있는 헤더 및 컨텐츠를 집계하기위한 응답 추상화를 생성하는 경향이 있으며, 이러한 추상화는 종종 양립 할 수 없습니다.
Ref: http://www.php-fig.org/psr/psr-7/meta/
superglobals 변수 ($ _get 및 $ _post)를 사용할 수 있지만 글로벌 Mutable 상태입니다. 이 장치와 함께 코드의 통합 테스트가 어려워집니다.
이러한 이유로 많은 PHP 프레임 워크는 HTTP 메시지를 나타내는 금욕을 구현하기로 결정했습니다 (예 : Symfony HttpFoundation 또는 Zend HTTP 참조).
이로 인해 모든 응용 프로그램이 HTTP 메시지의 특정 구현을 기반으로 한 상황이 발생하여 다른 프레임 워크를 사용하여 구축 된 프로젝트에서는 거의 사용할 수 없었습니다.
그렇기 때문에 일반적인 인터페이스 세트가 HTTP 메시지를 추상화하고 프레임 워크의 불가지론적인 방식으로 작업하는 데 도움이되는 이유입니다.
Ref: http://stackoverflow.com/questions/32805681/php-why-http-message-implementations
HTTP는 파일뿐만 아니라 리소스를 전송하는 데 사용됩니다. 리소스는 URL로 식별 할 수있는 일부 정보입니다 (URL의 r). 가장 일반적인 종류의 리소스는 파일이지만 리소스는 동적으로 생성 된 쿼리 결과, CGI 스크립트의 출력, 여러 언어로 제공되는 문서 또는 다른 문서 일 수도 있습니다.
ref :
* http://www.w3schools.com/tags/ref_httpmessages.asp
* https://www.jmarshall.com/easy/http/
