إعادة كتابة عناوين HTTP وعنوان URL مع بوابة التطبيق

تتيح لك Application Gateway إعادة كتابة المحتوى المحدد من الطلبات والاستجابات. باستخدام هذه الميزة، يمكنك ترجمة عناوين URL ومعلمات سلسلة الاستعلام بالإضافة إلى تعديل عناوين الطلبات والاستجابة. كما تسمح لك بإضافة شروط لضمان إعادة كتابة عنوان URL أو العناوين المحددة فقط عند استيفاء شروط معينة. وتستند هذه الشروط إلى معلومات الطلب والاستجابة.

إشعار

عنوان HTTP وخصائص إعادة كتابة عنوان URL متوفرة فقط ل بوابة التطبيق v2 SKU

أنواع إعادة كتابة معتمدة

عناوين الطلب والاستجابة

تتيح عناوين HTTP للعميل والخادم تمرير معلومات إضافية مع طلب أو استجابة. عن طريق إعادة كتابة هذه العناوين، يمكنك إنجاز مهمات حيوية، مثل إضافة حقول عنوان متعلق بالأمان مثل HSTS/ X-XSS-Protection، وإزالة حقول عنوان الاستجابة التي قد تكشف عن معلومات حساسة، وإزالة معلومات المنفذ من عناوين X-Forwarded-For.

تسمح لك بوابة التطبيق بإضافة عناوين طلب واستجابة HTTP أو إزالتها أو تحديثها أثناء انتقال حزم الطلب والاستجابة بين مجموعات العميل والواجهة الخلفية.

لتعلم كيفية إعادة كتابة عناوين الطلبات والاستجابة مع بوابة التطبيق باستخدام مدخل Azure، راجع هنا.

img

العناوين المدعومة

يمكنك إعادة كتابة كافة العناوين في الطلبات والاستجابات، باستثناء الاتصال وعناوين الترقية. يمكنك أيضا استخدام بوابة التطبيق لإنشاء عناوين مخصصة وإضافتها إلى الطلبات والاستجابات التي يتم توجيهها من خلالها.

مسار URL وسلسلة الاستعلام

مع إمكانية إعادة كتابة URL في Application Gateway، يمكنك:

  • إعادة كتابة اسم المضيف والمسار وسلسلة الاستعلام من عنوان URL المطلوب

  • اختر إعادة كتابة عنوان URL لجميع الطلبات على وحدة الاستماع أو فقط تلك الطلبات التي تطابق شرطاً أو أكثر من الشروط التي عينتها. تستند هذه الشروط إلى خصائص الطلب (عنوان الطلب ومتغيرات الخادم).

  • اختر مسار الطلب (حدد تجمع الخلفية) استنادا إلى عنوان URL الأصلي أو عنوان URL المعاد كتابته

لتعلم كيفية إعادة كتابة عناوين URL مع بوابة التطبيق باستخدام مدخل Azure، راجع هنا.

Diagram that describes the process for rewriting a URL with Application Gateway.

إعادة كتابة الإجراءات

يمكنك استخدام إجراءات إعادة كتابة لتحديد عنوان URL أو عناوين الطلبات أو عناوين الاستجابة التي تريد إعادة كتابتها والقيمة الجديدة التي تنوي إعادة كتابتها إليها. يمكن تعيين قيمة عنوان URL أو عنوان جديد أو موجود إلى هذه الأنواع من القيم:

  • النص
  • عنوان الطلب. لتحديد عنوان الطلب، تحتاج إلى استخدام بناء الجملة {http_req_ اسم العنوان}
  • عنوان الاستجابة. لتحديد عنوان الاستجابة، تحتاج إلى استخدام بناء الجملة {http_req_ اسم العنوان}
  • متغير الخادم. لتحديد متغير خادم، تحتاج إلى استخدام بناء الجملة {var_متغيّر الخادم}. راجع قائمة متغيرات الخادم المعتمدة
  • مجموعة من النصوص وعنوان الطلب وعنوان الاستجابة ومتغير الخادم.

شروط إعادة الكتابة

يمكنك استخدام إعادة كتابة الشروط، تكوين اختياري، لتقييم محتوى طلبات واستجابات HTTP(S) وتنفيذ إعادة كتابة فقط عند استيفاء شرطٍ واحدٍ أو أكثر. تستخدم application gateway هذه الأنواع من المتغيرات لتقييم محتوى الطلبات والاستجابات:

  • عناوين HTTP في الطلب
  • عناوين HTTP في الاستجابة
  • متغيرات خادم Application Gateway

يمكنك استخدام شرط لتقييم ما إذا كان متغير بعينه موجوداً، أو ما إذا كان متغير بعينه يطابق قيمةً معينة، أو ما إذا كان متغير بعينه يطابق نمطاً معين.

مطابقة النمط

تستخدم بوابة التطبيق تعابير عادية لمطابقة النمط في الشرط. يجب استخدام التعبيرات المتوافقة مع Regular Expression 2 (RE2) عند كتابة الشروط الخاصة بك. إذا كنت تقوم بتشغيل Application Gateway Web Application Firewall (WAF) مع مجموعة القواعد الأساسية 3.1 أو إصدار سابق، فقد تواجه مشكلات عند استخدام التعبيرات العادية المتوافقة مع Perl (PCRE) أثناء إجراء تأكيدات lookahead و lookbehind (سلبية أو إيجابية).

التقاط

لالتقاط سلسلة فرعية للاستخدام لاحقا، ضع أقواس حول الجزء الفرعي الذي يطابقها في تعريف الشرط regex. يخزن الزوج الأول من الأقواس سلسلة فرعية في 1، والزوج الثاني في 2، وهلم جرا. يمكنك استخدام العديد من الأقواس كما تريد؛ تواصل Perl فقط تعريف المزيد من المتغيرات المرقمة لك لتمثيل هذه السلاسل الملتقطة. بعض الأمثلة من مرجع:

  • (\d) (\d) # مطابقة رقمين، والتقاطهما في المجموعتين 1 و2

  • (\d+) # مطابقة رقم واحد أو أكثر، والتقاطها جميعا في المجموعة 1

  • (\d)+ # مطابقة رقم مرة واحدة أو أكثر، مع تسجيل الأخير في المجموعة 1

إشعار

/ يجب عدم تحديد استخدام للبادئة واللاحقة النمط في النمط لمطابقة القيمة. على سبيل المثال، سيتطابق (\d)(\d) مع رقمين. /(\d)(\d)/ لن يتطابق مع رقمين.

بمجرد التقاطهما، يمكنك الرجوع إليهما في مجموعة الإجراءات باستخدام التنسيق التالي:

  • لالتقاط عنوان طلب، عليك استخدام {http_req_headerName_groupNumber}. على سبيل المثال، {http_req_User-Agent_1} أو {http_req_User-Agent_2}
  • لالتقاط عنوان استجابة، يجب استخدام {http_resp_headerName_groupNumber}. على سبيل المثال، {http_resp_Location_1} أو {http_resp_Location_2}
  • بالنسبة إلى متغير الخادم، عليك استخدام {var_serverVariableName_groupNumber}. على سبيل المثال، {var_uri_path_1} أو {var_uri_path_2}

إشعار

يجب أن تتطابق حالة متغير الشرط مع حالة متغير الالتقاط. على سبيل المثال، إذا كان متغير الشرط الخاص بي هو User-Agent، فيجب أن يكون متغير الالتقاط الخاص بي ل User-Agent (أي {http_req_User-Agent_2}). إذا تم تعريف متغير الشرط الخاص بي على أنه عامل مستخدم، يجب أن يكون متغير الالتقاط الخاص بي لعامل المستخدم (أي {http_req_user-agent_2}).

إذا كنت تريد استخدام القيمة بأكملها، ينبغي عدم ذكر الرقم. ببساطة استخدام تنسيق {http_req_headerName}، وما إلى ذلك دون groupNumber.

متغيرات الخادم

تستخدم "بوابة التطبيق" متغيرات الخادم لتخزين معلومات مفيدة حول الملقم والاتصال مع العميل، والطلب الحالي على الاتصال. تتضمن أمثلة المعلومات المخزنة عنوان IP للعميل ونوع متصفح الويب. تتغير متغيرات الخادم بشكل حيوي، على سبيل المثال، عند تحميل صفحة جديدة أو عند نشر نموذج. يمكنك استخدام هذه المتغيرات لتقييم شروط إعادة الكتابة وإعادة كتابة العناوين. لاستخدام قيمة متغيرات الخادم لإعادة كتابة الرؤوس، ستحتاج إلى تحديد هذه المتغيرات في بناء الجملة {var_serverVariableName}

تدعم بوابة التطبيق متغيرات الخادم التالية:

اسم المتغير ‏‏الوصف
add_x_forwarded_for_proxy حقل عنوان طلب العميل X-Forwarded-For مع client_ipالمتغير (راجع الشرح لاحقا في هذا الجدول) الملحق به في نموذجIP1 IP2 IP3 وهلم جرا. إذا لم يكن الحقل X-Forwarded-For في عنوان طلب العميل، فإن add_x_forwarded_for_proxyالمتغير يساوي $client_ip المتغير. هذا المتغير مفيد بشكل خاص عندما تريد إعادة كتابة مجموعة عناوين X-إعادة توجيه-For بواسطة بوابة التطبيق بحيث يحتوي العنوان على عنوان IP فقط بدون معلومات المنفذ.
الأصفار_المدعومة قائمة الأصفار المعتمدة من قبل العميل.
الأصفار_المستخدمة سلسلة الأصفار المستخدمة في اتصال TLS ثابت.
client_ip عنوان IP للعميل الذي تلقت بوابة التطبيق الطلب منه. إذا كان هناك وكيل عكسي قبل بوابة التطبيق والعميل الأصلي، client_ipسيعيد عنوان IP من الوكيل العكسي.
منفذ_العميل منفذ العميل.
client_tcp_rtt معلومات حول اتصال TCP العميل. متوفر على الأنظمة التي تدعم خيار مأخذ التوصيل TCP_INFO.
المستخدم_العميل عند استخدام مصادقة HTTP يتم توفير اسم المستخدم للمصادقة.
مضيف في ترتيب الأسبقية هذا: اسم المضيف من خط الطلب أو اسم المضيف من حقل عنوان طلب المضيف أو اسم الخادم المطابق للطلب. مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، ستكون قيمة المضيف contoso.com
ملف تعريف الارتباط_الاسم ملف تعريف الارتباط الخاص ب الاسم.
http_method الأسلوب المستخدم في إجراء طلب عنوان URL. على سبيل المثال، احصل على أو انشر.
حالة_http حالة الجلسة. على سبيل المثال، 200, 400 أو 403.
إصدار بروتوكول الطلب. عادة HTTP/1.0 أو HTTP/1.1 أو HTTP/2.0.
سلسلة_الاستعلام قائمة أزواج المتغيرات/القيمة التي تتبع "؟" في عنوان URL المطلوب. مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، ستكون قيمة استعلام السلسلة id=123&title=fabrikam
البايت التي تم تسليمها طول الطلب (بما في ذلك خط الطلب وعنوانه ونص الطلب).
طلب_الاستعلام الوسيطات في خط الطلب.
نظام_الطلب نظام الطلب: http أو https.
طلب uri طلب URI الأصلي الكامل (مع الوسائط). مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam*، ستكون قيمة طلب_uri /article.aspx?id=123&title=fabrikam
البايت_المرسلة عدد البايت المرسلة إلى عميل.
منفذ_الخادم منفذ الخادم الذي قبل طلبا.
بروتوكول_اتصال_ssl بروتوكول اتصال TLS المؤسس.
ssl_ممكّن "تشغيل" إذا كان الاتصال يعمل في وضع TLS. وإلا، سلسلة فارغة.
مسار_uri يعرّف المورد المحدد في المضيف الذي يريد عميل الويب الوصول إليه. هذا هو جزء من عنوان URI للطلب دون الوسيطات. مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، ستكون قيمة مسار_uri /article.aspx

متغيرات خادم المصادقة المتبادلة

تدعم بوابة التطبيق متغيرات الخادم التالية لسيناريوهات المصادقة المتبادلة. استخدم متغيرات الخادم هذه بنفس الطريقة أعلاه مع متغيرات الخادم الأخرى.

اسم المتغير ‏‏الوصف
شهادة_العميل شهادة العميل بنموذج PEM لاتصال SSL مؤسس.
تاريخ_انتهاء_شهادة_العميل تاريخ انتهاء شهادة العميل.
بصمة_شهادة_العميل بصمة لوغاريتم التجزئة الآمن 1 لشهادة العميل لاتصال SSL المؤسس.
مُصدر_شهادة_العميل سلسلة "المُصدر DN" لشهادة العميل لاتصال SSL المؤسس.
الرقم التسلسلي_لشهادة_العميل الرقم التسلسلي لشهادة العميل لاتصال SSL المؤسس.
تاريخ_بداية_شهادة_العميل تاريخ بدء شهادة العميل.
موضوع_شهادة_العميل سلسلة "الموضوع DN" من شهادة العميل لاتصال SSL المؤسس.
التحقق من صحة_شهادة_العميل نتيجة التحقق من شهادة العميل: SUCCESS أو FAILED:<reason> أو NONE إذا لم تكن الشهادة موجودة.

إعادة كتابة التكوين

لتكوين قاعدة إعادة الكتابة، تحتاج إلى إنشاء مجموعة قواعد إعادة الكتابة وإضافة تكوين قاعدة إعادة الكتابة فيها.

تحتوي مجموعة قواعد إعادة الكتابة على:

  • طلب اقتران قاعدة التحويل: يُربط تكوين إعادة الكتابة بتكوين وحدة الاستماع المصدر عبر قاعدة التحويل. عند استخدام قاعدة تحويل أساسية، فإن تكوين إعادة الكتابة يكون مرتبطاً بوحدة الاستماع المصدر وهو إعادة كتابة عنوان عمومي. عند استخدام قاعدة تحويل مستندة إلى مسار، يُعرَّف تكوين إعادة الكتابة على مخطط مسار URL. في هذه الحالة، فإنه ينطبق فقط على مساحة المسار المحددة للموقع. يمكنك إنشاء مجموعات إعادة كتابة متعددة وتطبيق كل مجموعة من مجموعات إعادة الكتابة على وحدات استماع متعددة. ولكن يمكنك تطبيق مجموعة إعادة كتابة واحدة فقط على وحدة استماع معينة.

  • إعادة كتابة الشرط: إنه تكوين اختياري. إعادة كتابة الشروط يقيم محتوى طلبات واستجابات HTTP (S). سيحدث إجراء إعادة كتابة إذا كان طلب أو استجابة HTTP(S) أو يطابق شرط إعادة كتابة. إذا ربطت أكثر من شرط بإجراء، يحدث الإجراء فقط عند استيفاء جميع الشروط. بمعنى آخر، تُعد العملية عملية AND منطقية.

  • نوع إعادة الكتابة: هناك 3 أنواع من عمليات إعادة الكتابة المتوفرة:

    • إعادة كتابة عناوين الطلبات
    • إعادة كتابة عناوين الاستجابة
    • إعادة كتابة مكونات URL
      • مسار عنوان URL: القيمة التي يجب إعادة كتابة المسار إليها.
      • سلسلة استعلام عنوان URL: القيمة التي يتم إعادة كتابة سلسلة الاستعلام إليها.
      • إعادة تقييم مخطط المسار: يستخدم لتحديد ما إذا كان سيتم إعادة تقييم مخطط مسار URL أم لا. في حالة عدم تحديده، سيُستخدم مسار URL الأصلي لمطابقة نمط المسار في مخطط مسار URL. إذا تم تعيينه إلى صحيح، فستتم إعادة تقييم مخطط مسار URL للتحقق من التطابق مع المسار المعاد كتابته. يساعد تمكين هذا التبديل في توجيه الطلب إلى إعادة كتابة منشور لتجمع خلفي مختلف.

أعد كتابة الأخطاء الشائعة في التكوين

  • لا يسمح بتمكين "إعادة تقييم مخطط المسار" لقواعد توجيه الطلب الأساسية. هذا لمنع تكرار حلقي لتقييم لانهائي لقاعدة التحويل الأساسية.

  • يجب أن تكون هناك قاعدة إعادة كتابة شرطية أو قاعدة إعادة كتابة 1 على الأقل لا تحتوي على تمكين "إعادة تقييم مخطط المسار" لقواعد التوجيه المستندة إلى المسار لمنع تكرار حلقة التقييم اللانهائي لقاعدة التوجيه المستندة إلى المسار.

  • سيتم إنهاء الطلبات الواردة باستخدام التعليمة البرمجية خطأ 500 في حالة إنشاء تكرار حلقي بشكل حيوي استنادا إلى مدخلات العميل. ستستمر بوابة التطبيق بخدمة طلبات أخرى دون أي تدهور في سيناريو كهذا.

استخدام إعادة كتابة عنوان URL أو إعادة كتابة عنوان المضيف باستخدام جدار حماية تطبيق ويب (WAF_v2 SKU)

عند تكوين إعادة كتابة عنوان URL أو إعادة كتابة عنوان المضيف، سيتم إجراء تقييم WAF بعد تعديل عنوان الطلب أو معلمات URL (بعد إعادة الكتابة). عند إزالة إعادة كتابة عنوان URL أو عنوان المضيف أعد كتابة التكوين على "بوابة التطبيق" الخاصة بك، سيتم إجراء تقييم WAF قبل إعادة كتابة العنوان (قبل إعادة الكتابة). يضمن هذا الأمر تطبيق قواعد WAF على الطلب النهائي الذي سيتم استلامه بواسطة تجمع الخلفية.

على سبيل المثال، لنفترض أن لديك قاعدة إعادة كتابة العنوان التالية للعنوان "Accept" : "text/html" - إذا كانت قيمة العنوان "Accept" مساوية ل "text/html"، أعد كتابة القيمة إلى "image/png".

هنا، مع تكوين إعادة كتابة العنوان فقط، سيتم إجراء تقييم WAF على"Accept" : "text/html". ولكن عند تكوين إعادة كتابة عنوان URL أو إعادة كتابة عنوان المضيف، سيتم إجراء تقييم WAF على"Accept" : "image/png".

سيناريوهات شائعة لإعادة كتابة العنوان

إزالة معلومات المنفذ من X-Forwarded-For للعنوان

إدراج بوابة التطبيق X-Forwarded-For للعنوان في كافة الطلبات قبل أن يعيد توجيه الطلبات إلى الخلفية. هذا العنوان هو قائمة مفصولة بفاصلة لمنافذ IP. قد تكون هناك سيناريوهات تحتاج فيها خوادم الواجهة الخلفية فقط إلى العناوين لاحتواء عناوين IP. يمكنك استخدام إعادة كتابة الرأس لإزالة معلومات المنفذ من X-Forwarded-For للعنوان. إحدى الطرق للقيام بذلك هي تعيين العنوان إلى متغير الخادم add_x_forwarded_for_proxy. بدلا من ذلك، يمكنك أيضا استخدام المتغير client_ip:

Remove port

تعديل عنوان URL لإعادة التوجيه

يمكن أن يكون تعديل عنوان URL لإعادة التوجيه مفيدا في ظل ظروف معينة. على سبيل المثال: تمت إعادة توجيه العملاء في الأصل إلى مسار مثل "/blog" ولكن يجب الآن إرسالهم إلى "/updates" بسبب تغيير في بنية المحتوى.

تحذير

تأتي الحاجة إلى تعديل عنوان URL لإعادة التوجيه في بعض الأحيان في سياق تكوين حيث يتم تكوين بوابة التطبيق لتجاوز اسم المضيف نحو الخلفية. يختلف اسم المضيف كما تراه الواجهة الخلفية في هذه الحالة عن اسم المضيف كما يراه المستعرض. في هذه الحالة، لن تستخدم إعادة التوجيه اسم المضيف الصحيح. هذا التكوين غير مستحسن.

يتم وصف قيود وتأثيرات مثل هذا التكوين في الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به. الإعداد الموصى به لخدمة التطبيقات هو اتباع إرشادات "المجال المخصص (مستحسن)" في تكوين خدمة التطبيقات باستخدام بوابة التطبيق. يجب اعتبار إعادة كتابة عنوان الموقع على الاستجابة كما هو موضح في المثال أدناه حلا بديل ولا يعالج السبب الجذري.

عندما ترسل خدمة التطبيق استجابة إعادة توجيه، فإنها تستخدم نفس اسم المضيف في عنوان الموقع الخاص لاستجابتها مثل اسم المضيف في الطلب الذي تتلقاه من بوابة التطبيق. لذلك سيقوم العميل بإجراء الطلب مباشرة إلى contoso.azurewebsites.net/path2 بدلا من المرور عبر بوابة التطبيق (contoso.com/path2). من غير المرغوب تجاوز بوابة التطبيق.

يمكنك حل هذه المشكلة عن طريق تعيين اسم المضيف في عنوان الموقع إلى اسم مجال بوابة التطبيق.

فيما يلي الخطوات لاستبدال اسم المضيف:

  1. إنشاء قاعدة إعادة كتابة مع شرط تقييم ما إذا كان عنوان الموقع في الاستجابة يحتوي على azurewebsites.net. أدخل النمط(https?):\/\/.*azurewebsites\.net(.*)$.
  2. تنفيذ إجراء لإعادة كتابة عنوان الموقع بحيث يكون لديه اسم مضيف بوابة التطبيق. قم بذلك عن طريق إدخال {http_resp_Location_1}://contoso.com{http_resp_Location_2} كقيمة العنوان. بدلا من ذلك، يمكنك أيضا استخدام متغير الخادمhostلتعيين اسم المضيف لمطابقة الطلب الأصلي.

Modify location header

تنفيذ عناوين أمان HTTP لمنع الثغرات الأمنية

يمكنك إصلاح العديد من الثغرات الأمنية عن طريق تنفيذ العناوين الضرورية في استجابة التطبيق. تتضمن عناوين الأمان هذه X-XSS-الحماية، تدابير أمان صارمة للنقل، ونهج أمان المحتوى. يمكنك استخدام "بوابة التطبيق" لتعيين هذه العناوين لكافة الاستجابات.

Security header

حذف العناوين غير المرغوب فيها

قد تحتاج إلى إزالة عناوين تكشف معلومات حساسة من استجابة HTTP. على سبيل المثال، قد تحتاج إلى إزالة معلومات مثل اسم الخادم الخلفي أو نظام التشغيل أو تفاصيل المكتبة. يمكنك استخدام بوابة التطبيق لإزالة هذه العناوين:

Deleting header

التحقق من وجود عنوان

يمكنك تقييم عنوان طلب HTTP أو استجابة لوجود متغير عنوان أو ملقم شبكة. هذا التقييم مفيد عندما تريد إجراء إعادة كتابة عنوان فقط عند وجود عنوان معين.

Checking presence of a header

السيناريوهات الشائعة لإعادة كتابة عنوان URL

تحديد مسار يستند إلى المعلمة

لإنجاز وحدات السيناريو حيث تريد اختيار الخلفية استنادا إلى قيمة عنوان أو جزء من عنوان URL أو سلسلة استعلام في الطلب، يمكنك استخدام تركيبة من إمكانية إعادة كتابة عنوان URL وتوجيه مستند إلى المسار. على سبيل المثال، إذا كان لديك موقع تسوق وتم تمرير فئة المنتج كسلسلة استعلام في عنوان URL، وكنت تريد توجيه الطلب إلى الخلفية استنادا إلى سلسلة الاستعلام، عندئذ:

الخطوة الأولى: إنشاء مخطط مسار كما هو موضح في النسخة أدناه

URL rewrite scenario 1-1.

الخطوة 2 (أ): إنشاء مجموعة إعادة كتابة تحتوي على 3 قواعد إعادة كتابة:

  • القاعدة الأولى لديها شرط أن يتحقق من المتغير query_stringل فئة = الأحذية ولها إجراء يعيد كتابة مسار عنوان URL إلى /listing1 و إعادة تقييم مخطط المسار ممكنة

  • القاعدة الأولى لديها شرط أن يتحقق من المتغير query_stringل فئة = الأحذية ولها إجراء يعيد كتابة مسار عنوان URL إلى /listing2 و إعادة تقييم مخطط المسار ممكنة

  • القاعدة الأولى لديها شرط أن يتحقق من المتغير query_stringل فئة = الأحذية ولها إجراء يعيد كتابة مسار عنوان URL إلى /listing3 و إعادة تقييم مخطط المسار ممكنة

URL rewrite scenario 1-2.

الخطوة 2 (ب): إقران مجموعة إعادة الكتابة هذه بالمسار الافتراضي للقاعدة المستندة إلى المسار أعلاه

URL rewrite scenario 1-3.

الآن، إذا طلب المستخدم contoso.com/listing? فئة=أي، فستتم مطابقته مع المسار الافتراضي نظرا لأن أيا من أنماط المسار في مخطط المسار (/listing1 و/listing2 و/listing3) سوف يتطابق. بما أنك قمت بربط مجموعة إعادة كتابة أعلاه مع هذا المسار، سيتم تقييم مجموعة إعادة الكتابة هذه. نظرا لأن سلسلة الاستعلام لن تتطابق مع الشرط في أي من قواعد إعادة الكتابة الثلاثة في مجموعة إعادة الكتابة هذه، فلن يتم إجراء إعادة كتابة وبالتالي، سيتم توجيه الطلب دون تغيير إلى الخلفية المقترنة بالمسار الافتراضي (وهو GenericList).

إذا طلب المستخدم contoso.com/listing?فئة=أحذية، عندها ستتم مطابقة المسار الافتراضي مرة أخرى. ومع ذلك، في هذه الحالة، سيتطابق الشرط في القاعدة الأولى، وبالتالي، سيتم تنفيذ الإجراء المقترن بالشرط الذي سيعيد كتابة مسار URL إلى /listing1 وإعادة تقييم مخطط المسار. عند إعادة تقييم مخطط المسار، سيتطابق الطلب الآن مع المسار المقترن بالنمط /listing1 وسيتم توجيه الطلب إلى الخلفية المقترنة بهذا النمط، وهو ShoesListBackendPool.

إشعار

يمكن توسيع هذا السيناريو إلى أي عنوان أو قيمة ملف تعريف الارتباط أو مسار عنوان URL أو سلسلة الاستعلام أو متغيرات الخادم استنادا إلى الشروط المعرّفة وتمكنك بشكل أساسي من توجيه الطلبات استنادا إلى هذه الشروط.

إعادة كتابة معلمات سلسلة الاستعلام استنادا إلى عنوان URL

النظر في سيناريو موقع تسوق حيث ينبغي أن يكون الارتباط المرئي للمستخدم بسيطا و مقروءا، ولكن يحتاج الخادم الخلفي إلى معلمات سلسلة الاستعلام لإظهار المحتوى الصحيح.

في هذه الحالة، تستطيع بوابة التطبيق التقاط معلمات من عنوان URL وإضافة أزواج قيمة مفتاح سلسلة الاستعلام من تلك من عنوان URL. على سبيل المثال، لنفترض أن المستخدم يريد إعادة كتابة، https://www.contoso.com/fashion/shirts إلى https://www.contoso.com/buy.aspx?category=fashion&product=shirts، يمكن تحقيق ذلك من خلال تكوين إعادة كتابة عنوان URL التالي.

الشرط - إذا كان متغير الخادمuri_path يساوي النمط /(.+)/(.+)

URL rewrite scenario 2-1.

الإجراء - تعيين مسار عنوان URL إلى buy.aspx سلسلة الاستعلام إلى category={var_uri_path_1}&product={var_uri_path_2}

URL rewrite scenario 2-2.

للحصول على إرشاد خطوة بخطوة لتحقيق السيناريو الموضح أعلاه، راجع إعادة كتابة عنوان URL مع بوابة التطبيق باستخدام مدخل Azure

إعادة كتابة عنوان URL مقابل إعادة توجيه عنوان URL

لإعادة كتابة عنوان URL، تعيد بوابة التطبيق كتابة عنوان URL قبل إرسال الطلب إلى الخلفية. لن يؤدي ذلك إلى تغيير ما يراه المستخدمون في المستعرض لأن التغييرات مخفية عن المستخدم.

لإعادة توجيه عنوان URL، ترسل بوابة التطبيق استجابة إعادة توجيه إلى العميل بعنوان URL الجديد. وهذا بدوره يتطلب من العميل إعادة إرسال طلبه إلى عنوان URL الجديد المقدم في إعادة التوجيه. سيتم تحديث عنوان URL الذي يراه المستخدم في المتصفح إلى عنوان URL الجديد.

Rewrite vs Redirect.

القيود

  • إذا كان لدى استجابة عنوان واحد أو أكثر بنفس الاسم، عندئذ ستؤدي إعادة كتابة قيمة أحد هذه العناوين إلى إسقاط عناوين أخرى في الاستجابة. يمكن أن يحدث هذا عادة مع عنوان مجموعة ملف تعريف الارتباط بما أنك تستطيع الحصول على عنوان مجموعة ملف تعريف ارتباط واحد أو أكثر في استجابة. أحد هذه السيناريوهات هو عندما تستخدم خدمة تطبيق مع بوابة تطبيق وقمت بتكوين ترابط الجلسة المستندة إلى ملفات تعريف الارتباط على بوابة التطبيق. في هذه الحالة، ستحتوي الاستجابة على عنواني مجموعة ملفات تعريف الارتباط: أحدهما تستخدمه خدمة التطبيق، على سبيل المثال: Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net والآخر ترابط بوابة التطبيق، على سبيل المثال، Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. إعادة كتابة أحد عناوين مجموعة ملفات تعريف الارتباط في هذا السيناريو يمكن أن يؤدي إلى إزالة عنوان مجموعة ملفات تعريف الارتباط الأخرى من الاستجابة.
  • لا يتم دعم عمليات إعادة الكتابة عند تكوين بوابة التطبيق لإعادة توجيه الطلبات أو لإظهار صفحة خطأ مخصصة.
  • يمكن أن تحتوي أسماء عناوين الطلب على أحرف أبجدية رقمية وواصلات. سيتم تجاهل أسماء الرؤوس التي تحتوي على أحرف أخرى عند إرسال طلب إلى هدف الواجهة الخلفية.
  • يمكن أن تحتوي أسماء عناوين الاستجابة على أي أحرف أبجدية رقمية ورموز محددة كما هو محدد في RFC 7230.
  • لا يمكن إعادة كتابة عناوين الاتصال والترقية
  • عمليات إعادة الكتابة غير مدعومة لاستجابات 4xx و5xx التي تم إنشاؤها مباشرة من بوابة التطبيق

الخطوات التالية