تحدثنا في المقالات السابقة عن عدة جوانب رئيسية لإعادة كتابة عنوان URL. في المقالة الأخيرة من هذه السلسلة، سنناقش بعض التفاصيل والخصائص للمستويات المختلفة لإعادة كتابة عنوان URL.
من الناحية النظرية، تتمتع إعادة كتابة عنوان URL على مستوى IIS المكتوب بلغة C أو C++ بأداء أعلى من إعادة كتابة عنوان URL على مستوى ASP.NET المكتوب في تعليمات برمجية مُدارة. لكنني أعتقد أن الفرق في هذا المجال لا يذكر في معظم الحالات، ويكاد يكون من المستحيل أن يتحول هذا الأداء إلى عنق الزجاجة في الأداء. ولذلك، فإن مستوى إعادة كتابة عنوان URL الذي تم اختياره لا يتم تحديده بشكل عام وفقًا لمتطلبات أداء التطبيق الخاص بك. إذن ما هو مستوى إعادة كتابة عنوان URL الذي يجب استخدامه؟ بعد استخدام مستويات مختلفة من إعادة كتابة عنوان URL، ما الذي يجب أن ننتبه إليه؟ أنا هنا للحديث عن آرائي الشخصية.
على الرغم من أن مكون إعادة كتابة عنوان URL الحالي يمكن أن يلبي معظم التطبيقات من حيث الوظائف، إلا أننا في مرحلة ما، لا نزال بحاجة إلى بعض الوظائف الخاصة. على سبيل المثال، ليس من السهل تحقيق إعادة كتابة عنوان URL استنادًا إلى اسم المجال باستخدام مكون إعادة كتابة عنوان URL الحالي. يمكن لـ ISAPI Rewrite التجاري أن يدعم هذا حاليًا، ولسوء الحظ، فإن UrlRewriter.NET وIIRF مفتوحي المصدر ليس لهما وظائف كافية في هذا الصدد. وتتم مطابقتها جميعًا بناءً على مسار الطلب المتعلق بالموقع، ولا يمكن استخدام اسم المجال المطلوب كشرط مطابقة. وهذا يتطلب منا توسيع مكون إعادة كتابة عنوان URL. بالنسبة لمعظم مطوري .NET، فإن التعليمات البرمجية المُدارة هي بطبيعة الحال الخيار الأول للتطوير. في هذا الوقت، قد يكون من الضروري اختيار مكون إعادة كتابة عنوان URL على مستوى ASP.NET. ومع ذلك، يمكن العثور على العديد من أمثلة الامتدادات على الإنترنت، سواء كان UrlRewriter.NET على مستوى ASP.NET أو IIRF على مستوى IIS.
ولكن في الواقع، إذا أردنا تحقيق الوظائف المذكورة أعلاه، فيمكننا أيضًا القيام بذلك في خطوتين. نستخدم أولاً IIRF لإعادة كتابة عنوان URL على مستوى IIS، ثم نستخدم إعادة كتابة عنوان URL على مستوى ASP.NET. على سبيل المثال، إذا أردنا الآن إعادة كتابة " http://jeffz.domain.com/articles " إلى "/ArticleList.aspx?owner=jeffz"، فيمكننا أولاً السماح لـ IIRF بإجراء أول إعادة كتابة لعنوان URL، بغرض إعادة الكتابة تتم إعادة كتابة "/articles" إلى "/ArticleList.aspx".
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
بهذه الطريقة، سيتلقى محرك ASP.NET مباشرة طلبًا لـ /ArticleList.aspx. ثم داخل ASP.NET، يمكننا إجراء إعادة كتابة عنوان URL الثاني (من أجل الراحة، ما زلت أكتبه في Global.asax، ويوصى باستخدام HttpModule إضافي في المشروع).
Application_BeginRequest باطل محمي ( مرسل الكائن ، EventArgs e)
{
HttpContext context = HttpContext .Current;
مضيف السلسلة = context.Request.Url.Host;
مالك السلسلة = host.Substring(0, host.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?owner=" +owner);
}
بعد إعادة كتابة عنوان URL مرتين، تم تحقيق التأثير الذي نريده (في المشاريع الفعلية، لا يمكن استخدام الكود أعلاه مباشرة لأنه يحتاج إلى الحكم على ما إذا كانت هناك سلسلة استعلام، وما إلى ذلك).
بالإضافة إلى ذلك، يمكن أن تعمل إعادة كتابة عنوان URL على مستوى ASP.NET فقط في ASP.NET (شيء واضح). إذا كنت تريد إعادة كتابة عنوان URL لدعم تقنيات الخادم الأخرى مثل PHP وRoR وما إلى ذلك، فيمكنك فقط استخدام إعادة كتابة عنوان URL على مستوى IIS. (أو وظيفة إعادة كتابة عنوان URL الأخرى التي توفرها تقنية الخادم).
لا يُسمح لبعض الأحرف الخاصة بالظهور في عناوين URL، أو بمجرد ظهورها في عناوين URL، يتغير معنى الطلب. على سبيل المثال، نحتاج إلى إعادة كتابة عنوان URL في صفحة البحث، وإعادة كتابة "/Search/xxx" إلى "/Search.aspx?xxx"، ثم الحصول على الكلمات الرئيسية التي قدمها المستخدم بناءً على السلسلة بعد علامة الاستفهام. إذا كنت تستخدم UrlRewriter.NET، فسنستخدم التكوين
التالي : <rewriter>
< إعادة الكتابة URL = " ^/بحث/(.+)$ " إلى = " ~/Search.aspx?$1 " المعالجة = " إيقاف " />
</ rewriter >
في الظروف العادية، تعمل إعادة كتابة عنوان URL هذا بشكل طبيعي. ولكن إذا استخدم المستخدم "%" ككلمة رئيسية، فسيختلف الوضع، لأننا سنتلقى رسالة الخطأ التالية:
وذلك لأن "%" غير مسموح به في عنوان URL. يمكنك الذهاب إلى مواقع الويب المختلفة ومحاولة طلب بعض المسارات مثل "ABC%25DEF" ("%25" متبوعة بـ "%")، وستجد معظمها أخطاء "400 طلب غير صحيح". ومع ذلك، من القانوني وضع "%" في سلسلة الاستعلام - نعم، ألم نعيد كتابة الكلمة الأساسية في سلسلة الاستعلام؟ لماذا لا يزال يعمل؟ يتم تحديد ذلك أيضًا من خلال طريقة تنفيذ ASP.NET.
يتم تحديد الطلب السيئ في الخطوة 3 من الشكل أعلاه، أي بينما لا يزال قيد التهيئة. تتم إعادة كتابة عنوان URL الخاص بنا فقط في حدث BeginRequest في الخطوة 4. عندما يحتوي الطلب على أحرف غير قانونية، ليس لدينا فرصة لإعادة كتابة عنوان URL على الإطلاق.
إذن كيف نتعامل مع هذه المشكلة؟ في الظروف العادية، لن تكون هناك مشكلة كبيرة إذا قمنا بإزالة % من العميل (بعض المواقع تفعل ذلك)، ولكن ماذا لو كان علينا الاحتفاظ بها؟ ثم استخدم سلسلة الاستعلام لتمرير المعلمات، أو يمكننا أيضًا استخدام إعادة كتابة عنوان URL لمستوى IIS. لا تزال تأخذ IIRF كمثال:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
عندما يتم إرسال الطلب إلى IIS (الخطوة 1)، وبعد تحديد ISAPI الذي يجب تسليمه انتهى للتنفيذ (الخطوة 2) حدثت إعادة كتابة عنوان URL من قبل. بعد إعادة كتابة عنوان URL، تم نقل "%" الموجود في العنوان إلى سلسلة الاستعلام، ويكون ذلك قانونيًا بشكل طبيعي عندما يتم تسليمه إلى ASP.NET للمعالجة.
أخيرًا، دعونا نناقش تكوين صفحة الخطأ. على سبيل المثال، بشكل عام، سنقوم بتكوين صفحة خطأ 404 للتطبيق، بحيث عندما يصل المستخدم إلى مورد غير موجود، يمكننا أن نظهر له صفحة معينة بدلاً من مطالبة الخطأ الافتراضية. ولكن في هذه المرحلة، يجب تكوين مستويات مختلفة من إعادة كتابة عنوان URL باستخدام طرق مختلفة.
إذا استخدمنا إعادة كتابة عنوان URL على مستوى ASP.NET، فعادةً ما قمنا بإعداد Wildcard Mapping في IIS، بحيث تتم معالجة أي طلب (بما في ذلك html وjpg وما إلى ذلك) بواسطة ASP.NET. إذا تم طلب مورد غير موجود، فسيتم إصدار خطأ 404 بواسطة ASP.NET، لذلك يجب تكوين صفحة الخطأ 404 في web.config:
< customErrors الوضع = " تشغيل " defaultRedirect = " GenericErrorPage.htm " >
< خطأ رمز الحالة = " 404 " إعادة التوجيه = " FileNotFound.htm " />
</ customErrors >
إذا استخدمنا إعادة كتابة عنوان URL لمستوى IIS، فلن نقوم بتكوين تعيين Wildcard. بمعنى آخر، لن يبدأ محرك ASP.NET في العمل إلا عندما يكون العنوان بعد إعادة الكتابة هو aspx (أو أشياء أخرى كان من المفترض أن يعالجها ASP.NET ISAPI). إذا طلب المستخدم موردًا غير موجود، فسيتم إصدار خطأ 404 بواسطة IIS. في هذا الوقت، يجب تكوين صفحة الخطأ 404 في IIS:
تمت مناقشة موضوع إعادة كتابة عنوان URL حتى الآن. في التطوير الفعلي، ستواجه بالتأكيد العديد من المواقف المختلفة، ولكن طالما أنك تفهم مفتاح طريقة إعادة كتابة عنوان URL وتفكر وفقًا للطريقة التي يعمل بها البرنامج، أعتقد أنك لن تواجه مشكلات صعبة بشكل عام.