ASP.NET Core / الأساسي: HTTP وتركيب التطبيق / الدرس 1
الاستضافة وعقد HTTP
افصل المضيف والخادم وخط الطلب وعقد التطبيق قبل بناء نقطة نهاية.
في هذه الصفحة
أهداف الدرس
- شرح تحول طلب HTTP إلى HttpContext.
- تمييز تسجيل الخدمات من تركيب الخط.
- فحص طلبات اصطناعية دون بدء خادم.
للمضيف والتطبيق مسؤوليتان مختلفتان
يركب ASP.NET Core مضيفا وخادم HTTP وخدمات وبرمجيات وسيطة ونقاط نهاية. يدير المضيف عمر التطبيق وإعداده، ويتولى خادم مثل Kestrel الاتصالات ويقدم الطلب للتطبيق. يعمل الوسطاء والنقاط على HttpContext. لا تحدد صياغة C# وحدها التوجيه أو أعمار الاعتماد أو دلالة HTTP.
يوفر منشئ WebApplication الحديث افتراضيات مريحة، لكنها تقرأ إعدادا وتختار سلوكا. سجل الإطار وSDK والبيئة والتجاوزات الصريحة. تستخدم الدورة مكونات في الذاكرة بدلا من إطلاق مضيف، فلا يعني ذلك فحص منفذ أو شهادة أو وكيل أو تطبيق منشور.
يحمل سياق الطلب مدخلات مستقلة
لطلب HTTP طريقة ومسار واستعلام ورؤوس وجسم محتمل. ويعرض HttpContext ميزات الاتصال والنقطة المختارة والمستخدم والخدمات ذات النطاق والإلغاء وحالة الاستجابة. قد تأتي القيم من حدود ثقة مختلفة؛ فليس الرأس الممرر حقيقة عميل موثوقة تلقائيا، ولا قيمة المسار برهان تفويض.
ينشئ البرنامج الأول طلبا اصطناعيا ويقرأ طريقته ومساره واستعلامه باستخدام كائنات الإطار دون مستمع أو عميل. يثبت الخرج القيم المسندة فقط، ولا يختبر تحليل URL عند حد الشبكة أو سلوك وكيل عكسي.
using System;
using Microsoft.AspNetCore.Http;
var context = new DefaultHttpContext();
context.Request.Method = HttpMethods.Get;
context.Request.Path = "/reports";
context.Request.QueryString = new QueryString("?page=2");
Console.WriteLine($"{context.Request.Method} {context.Request.Path} page={context.Request.Query["page"]}");
GET /reports page=2
يعرض DefaultHttpContext الطريقة والمسار والاستعلام الاصطناعيين؛ ولا يستقبل أي خادم HTTP حركة شبكة.
تشكل الحالة والرؤوس والجسم عقد استجابة واحدا
اختر رمز الحالة وفق العملية: النجاح والمدخل غير الصالح والغياب والمصادقة والتفويض والتعارض وفشل الخادم نتائج مختلفة. اضبط النوع والرؤوس قبل اعتماد الاستجابة. قد تجعل JSON بحالة 200 لكل فشل العميل يخمن النجاح، وتضلل المراقبة والمخابئ.
يكتب البرنامج الثاني استجابة ثابتة إلى MemoryStream ويفحص حالتها وجسمها. يختبر الإسناد والكتابة على مستوى التطبيق. لا تعيد ميزات الذاكرة كل سلوك اعتماد الرؤوس والنقل في Kestrel؛ لذلك لا تثبت التجربة دلالة الاستجابة على السلك.
using System;
using System.IO;
using System.Text;
using Microsoft.AspNetCore.Http;
var context = new DefaultHttpContext();
using var body = new MemoryStream();
context.Response.Body = body;
context.Response.StatusCode = StatusCodes.Status202Accepted;
context.Response.ContentType = "text/plain; charset=utf-8";
await context.Response.WriteAsync("queued");
Console.WriteLine($"{context.Response.StatusCode} {Encoding.UTF8.GetString(body.ToArray())}");
202 queued
تحوي الاستجابة المسندة بحالة 202 النص queued في مجرى جسمها المحلي؛ ولا ترسل استجابة عبر الشبكة.
لا ينفذ تسجيل الخدمة مرحلة طلب
يصف تسجيل الخدمة كيفية إنشاء الاعتماد، ويصف تركيب الخط الوسطاء العاملين وترتيبهم، ويصف تعيين النقطة العمليات المرشحة وبياناتها. ليست خدمة مضافة إلى DI وسيطا تلقائيا، وليس إعلان نقطة عملية خلفية. أبق أشكال الإعداد الثلاثة منفصلة.
ينبغي التحقق من الإعداد المطلوب قبل قبول العمل. تجنب إنشاء مزود إضافي أثناء التسجيل أو إطلاق مهام بلا مالك في منشئ؛ فقد يكرر ذلك singleton أو يلتقط نطاقا خاطئا أو يتجاوز الإغلاق. تفصل الدروس اللاحقة عقود العمر المناسبة.
للفحص المحلي حد دليل محدد
حدد ما يفحصه المثال فعلا: كائن إطار أو مفوض أو نمط مسار أو سياسة أو تكامل مضيف أو شبكة أو وكيل أو قاعدة. الاستدعاء المباشر مفيد للحتمية، لكنه لا يفحص الربط أو وسيط المصادقة أو ترجمة المزود إلا إذا ضمها. ليس نجاح برنامج طرفية شهادة API منشورة.
احفظ المصدر وخصائص المشروع ونسخ SDK والإطار والمدخل الاصطناعي والمتوقع. استخدم مشروعا مؤقتا معزولا دون مصادر حزم خارجية. تبقى مقتطفات الإعداد غير المنفذة غير قابلة للتشغيل، ويحتاج النشر مساره المخول المستقل عن نجاح الدرس.
الأخطاء الشائعة وإصلاحها
يتوقع أن يعالج تسجيل DI الطلبات وحده.
- لماذا يحدث؟
- اختلط إنشاء الاعتماد بتنفيذ خط الطلب.
- كيف تصلحه؟
- ركب الوسيط أو نقطة النهاية المعنيين صراحة.
- كيف تتجنب تكراره؟
- راجع التسجيل وتركيب الخط وتعيين النقاط كلا على حدة.
يعاد كل خطأ بحالة 200.
- لماذا يحدث؟
- لا تتفق نتيجة النقل مع حمولة المجال.
- كيف تصلحه؟
- حدد عقد الحالة والجسم لكل فئة من فئات الفشل.
- كيف تتجنب تكراره؟
- اختبر الحالة والمحتوى معا.
يوصف اختبار سياق مباشر بأنه اختبار HTTP منشور.
- لماذا يحدث؟
- تجاوز ادعاء التحقق نطاق ما نفذ فعلا.
- كيف تصلحه؟
- حدد طبقات الإطار التي استدعاها الاختبار بالفعل.
- كيف تتجنب تكراره؟
- افصل دليل فحص المكون عن دليل التكامل.
اختبر فهمك
1. تعيد نقطة نهاية إقرارا بعمل أدرج في صف. لماذا قد تكون 202 أصدق من جسم يقول إن العمل انتهى مع حالة 200؟
اعرض الحل المشروح
إذا قبلت العملية العمل دون إكمال أثر الأعمال الموعود، فقد تعبر 202 بصدق عن قبول غير متزامن ضمن عقد متابعة موثق. حدد معرف العملية واستعلام حالتها وسياسة الإعادة وعدم تكرار الأثر وتقرير الفشل. لا يبني الرمز وحده هذه الآليات، ولا يجوز ادعاء الاكتمال لمجرد إدراج سجل في الصف.
2. ما الدليل الإضافي المطلوب، بعد مثال الاستجابة في الذاكرة، للتحقق من السلوك المواجه لوكيل عكسي؟
اعرض الحل المشروح
اختبر مسار مضيف ووكيل معزولا مخولا يشمل الرؤوس والمخطط والمضيف واعتماد الحالة والاتصال ومتطلبات التطبيق. تحقق من الثقة في الرؤوس الممررة وإنهاء TLS. يفحص مخزن الذاكرة الحالة والنص المسندين فقط؛ ولا يثبت ما يراه العميل الفعلي أو ما ينبغي الوثوق به من رؤوس خارجية.
أهم ما تعلمته
- المضيف والخادم والخدمات والوسيط والنقطة حدود مختلفة.
- تصف الحالة والحمولة النتيجة نفسها.
- طابق الادعاء بطبقات التحقق الفعلية.