إعادة كتابة عنوان URL (1): IIS باستخدام ASP.NET

لفهم المواضيع التي تمت مناقشتها لاحقًا في المقالة بشكل كامل، يجب أن نفهم بإيجاز عملية الاتصال بين IIS وASP.NET. ما أشرحه هنا هو خادم IIS 6. أما بالنسبة لـ IIS 5 وIIS 7، فيمكن القول أنه تم التخلص من الأول، في حين أن "الوضع الكلاسيكي" للأخير هو تمامًا نفس IIS 6، ويتحدث "وضع خط الأنابيب" الجديد بالفعل عن بعض المفاهيم في ASP. NET وIIS التكامل العميق. أعتقد أنه إذا فهمت IIS 6 وASP.NET، فلن تواجه أي مشاكل في الوضع المتكامل لـ IIS 7.

أولاً، دعونا نلقي نظرة على رسم تخطيطي بسيط، يوضح العديد من الخطوات الرئيسية في عملية IIS بأكملها بدءًا من تلقي الطلب وحتى إرجاع الاستجابة:

1. يتلقى IIS الطلب.
2. يقوم المحدد بتحديد ISAPI للتعامل مع الطلب بناءً على خصائص عنوان URL والتكوين في IIS - من الطبيعي الآن اختيار ASP.NET ISAPI.
3. يتلقى محرك تنفيذ ASP.NET الطلب ويقوم بتهيئة البيانات (مثل إنشاء كائنات مختلفة).
4. ابدأ في تشغيل العديد من أحداث Pipeline، بدءًا بشكل طبيعي بـ BeginRequest.
5. بعد عدة أحداث Pipeline، يحدد ASP.NET معالجًا أو HandlerFactory مناسبًا للطلب الحالي وفقًا للتكوين (باستثناء الظروف الخاصة، مثل إخراج النتائج مباشرة وإنهاء الطلب في الحدث السابق).
6. بعد معالجته بواسطة المعالج، يمر عبر العديد من أحداث Pipeline وينتهي بـ EndRequest.
7. استجابة الإخراج.

إذا كنت تريد إجراء إعادة كتابة عنوان URL في تطبيق ASP.NET، فعادةً ما تقوم باستدعاء أسلوب RewritePath الخاص بـ HttpContext في حدث BeginRequest لإعادة وضع الطلب على عنوان URL المستهدف. على سبيل المثال، يمكننا تجاوز طريقة Application_BeginRequest في Global.asax لتحقيق ذلك:

السبب وراء إجراء إعادة الكتابة في BeginRequest هو أن هذا الحدث هو الحدث الأقدم الذي تم تشغيله بين جميع أحداث Pipeline. بعد إعادة تحديد الموضع في هذا الوقت، تغيرت أيضًا بعض الخصائص في HttpContext الحالي وفقًا لذلك (مثل HttpContext.Request.Path). بهذه الطريقة، سوف يتأثر منطق المعالج لأحداث المسار التالية. على سبيل المثال، عندما يلزم تحديد الأذونات بناءً على دليل، سيتم استخدام المسار "المحدد" بدلاً من الطلب الذي يتلقاه ASP.NET. وبطبيعة الحال، فإن التغيير الأكثر "أهمية" هو اختيار المعالج. على سبيل المثال، في المثال أعلاه، قمنا بنقل الطلب إلى ملف "CustomerList.aspx"، بحيث يقوم محرك ASP.NET بتحديد System.Web.UI. المطابق لـ *.aspx تعالج فئة PageHandlerFactory الطلبات.

الفئة العامة العالمية : System.Web
{
    Application_BeginRequest باطل محمي (مرسل الكائن ، EventArgs e)
    {
        HttpContext context = HttpContext .Current;
 
        إذا (context.Request.Path.Equals( "/Customers" ,
            StringComparison .InvariantCultureIgnoreCase))
        {
            context.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

أخيرًا، هناك مفهومان يجب التمييز بينهما، وهما "ASP.NET Pipeline" و"Web Forms". كلاهما نموذجان مهمان في ASP.NET، لكن الاختلافات لا تزال كبيرة جدًا:

• خط أنابيب ASP.NET: مثل كل طلب يتلقاه تطبيق ASP.NET، ستتم معالجته من خلال "خط الأنابيب" هذا. هذا نموذج مستوى ASP.NET.
• نماذج الويب: أثناء تنفيذ خط أنابيب ASP.NET، تتمثل إحدى الخطوات في تحديد معالج (أو HandlerFactory) مناسب للتعامل مع الطلب. إذا كانت صفحة aspx، فسيختار ASP.NET فئة System.Web.UI.PageHandlerFactory، والتي يتم فيها تكوين نموذج WebForms أخيرًا.

في الواقع، كلمة "نموذج" في الجملة أعلاه قد لا تكون دقيقة. لأن نماذج الويب ربما تكون محرك تنفيذ ونموذجًا يمكن استخدامه بشكل مستقل، ويستخدم System.Web.UI.PageHandlerFactory هذا النموذج فقط. عندما نكتب تطبيقات ASP.NET، يمكننا استخدام هذا النموذج في أماكن أخرى وفقًا لاحتياجاتنا. على سبيل المثال، في المقالة " التقنية: استخدام التحكم في المستخدم لإنشاء HTML "، نستخدم ascx كقالب في معالج عام لإنشاء المحتوى.