php frameworks
1.0.0
يعتبر الوسيطة مصطلحًا عامًا للبرامج التي تعمل على "Glue Together" برامج منفصلة ، غالبًا ما تكون معقدة وقائمة بالفعل. تشمل بعض مكونات البرامج المرتبطة بشكل متكرر بالبرامج الوسيطة تطبيقات المؤسسات وخدمات الويب.
المرجع:
* 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 محدد ، ستحتاج إلى استخدام وظيفة الرأس ().
*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 من نفس المشكلة مثل حليقة ، وكذلك حقيقة أنه كان لديه تقليديًا أمثلة أقل بكثير من الاستخدام.
تميل معظم مكتبات عملاء 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 واجهات برمجة تطبيقات الخادم (SAPI) لتفسير طلبات HTTP الواردة ، ومدخلات المارشال ، ونقل المعالجة إلى البرامج النصية. تعكس تصميم SAPI الأصلي واجهة البوابة المشتركة ، والتي من شأنها أن تطلب البيانات ودفعها إلى متغيرات البيئة قبل نقل التفويض إلى البرنامج النصي ؛ سيسحب البرنامج النصي من متغيرات البيئة من أجل معالجة الطلب وإعادة استجابة.
ملخصات تصميم SAPI من PHP ، مصادر الإدخال الشائعة مثل ملفات تعريف الارتباط ، وسيطات سلسلة الاستعلام ، ومحتوى النشر المشفرة عن URL عبر superglobals ($ _cookie ، $ _get ، و $ _post ، على التوالي) ، وتوفير طبقة من الراحة لمطوري الويب.
...
الاستخدام المباشر لـ SuperGlobals لديه عدد من المخاوف. أولاً ، هذه قابلة للتغيير ، مما يجعل من الممكن للمكتبات والرمز تغيير القيم ، وبالتالي تغيير الحالة للتطبيق. بالإضافة إلى ذلك ، فإن SuperGlobals تجعل اختبار الوحدة والتكامل صعبة وهشة ، مما يؤدي إلى تدهور جودة الكود.
...
أخيرًا ، عندما يتعلق الأمر بالاستجابات من جانب الخادم ، فإن PHP يحصل بطريقته الخاصة: أي محتوى ينبعث قبل مكالمة إلى Header () سيؤدي إلى أن تصبح هذه المكالمة محدودة ؛ اعتمادًا على إعدادات الإبلاغ عن الخطأ ، قد لا يعني ذلك غالبًا الرؤوس و/أو حالة الاستجابة لا يتم إرسالها بشكل صحيح. تتمثل إحدى الطرق في ذلك حول هذا إلى استخدام ميزات التخزين المؤقت لـ PHP ، ولكن تعشش المخازن المؤقتة للإخراج يمكن أن يصبح مشكلة ويصعب تصحيحه. وبالتالي تميل الأطر والتطبيقات إلى إنشاء تجريدات استجابة لتجميع الرؤوس والمحتوى الذي يمكن أن ينبعث في وقت واحد - وغالبًا ما تكون هذه التجريدات غير متوافقة.
Ref: http://www.php-fig.org/psr/psr-7/meta/
يمكنك استخدام متغيرات SuperGlobals (مثل $ _get و $ _post) ، لكنها حالة قابلة للتغيير عالمية. جنبا إلى جنب مع هذه الوحدة واختبار تكامل الكود الخاص بك يصبح صعبا.
للاطلاع على هذه الأسباب ، قررت العديد من أطر عمل PHP تنفيذ التصويت لتمثيل رسائل HTTP (انظر على سبيل المثال Symfony httpfoundation أو zend http).
أدى ذلك إلى موقف استند فيه أي تطبيق إلى تنفيذ محدد لرسائل HTTP ، بحيث لم يكن قابلاً للاستخدام في المشاريع المصممة باستخدام أطر أخرى.
هذا هو السبب في أن مجموعة شائعة من الواجهات تساعد رسائل HTTP المجردة والعمل معها بطريقة غير ملائمة للإطار.
Ref: http://stackoverflow.com/questions/32805681/php-why-http-message-implementations
يتم استخدام HTTP لنقل الموارد ، وليس فقط الملفات. المورد هو بعض المعلومات التي يمكن تحديدها بواسطة عنوان URL (إنه R في عنوان URL). النوع الأكثر شيوعًا من الموارد هو ملف ، ولكن قد يكون المورد أيضًا نتيجة استعلام تم إنشاؤه ديناميكيًا ، أو إخراج البرنامج النصي CGI ، أو وثيقة متوفرة بعدة لغات ، أو أي شيء آخر.
المرجع:
* http://www.w3schools.com/tags/ref_httpmessages.asp
* https://www.jmarshall.com/easy/http/
