مشاركة عبر

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

  • مقالة

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

إشعار

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

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

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

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

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

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

رسم تخطيطي يوضح الرؤوس في حزم الطلب والاستجابة.

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

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

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

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

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

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

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

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

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

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

يتم استخدام إجراءات إعادة الكتابة لتحديد عنوان URL. اطلب رؤوسا أو رؤوس استجابة تريد إعادة كتابتها وقيمة وجهة عنوان 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}

إشعار

يجب أن تتطابق حالة متغير الشرط مع حالة متغير الالتقاط. على سبيل المثال، إذا تم تعريف متغير الشرط على أنه عامل المستخدم، يجب أن يكون متغير الالتقاط لعامل المستخدم ({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-Forwarded-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، query_string القيمة هي id=123&title=fabrikam
البايت التي تم تسليمها طول الطلب (بما في ذلك خط الطلب وعنوانه ونص الطلب).
طلب_الاستعلام الوسيطات في خط الطلب.
نظام_الطلب نظام الطلب: http أو https.
طلب uri طلب URI الأصلي الكامل (مع الوسائط). مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam*، request_uri القيمة هي /article.aspx?id=123&title=fabrikam
البايت_المرسلة عدد البايت المرسلة إلى عميل.
منفذ_الخادم منفذ الخادم الذي قبل طلبا.
بروتوكول_اتصال_ssl بروتوكول اتصال TLS المؤسس.
ssl_ممكّن "تشغيل" إذا كان الاتصال يعمل في وضع TLS. وإلا، سلسلة فارغة.
مسار_uri يعرّف المورد المحدد في المضيف الذي يريد عميل الويب الوصول إليه. يشير المتغير إلى مسار URL الأصلي، قبل أي معالجة. هذا هو جزء من عنوان URI للطلب دون الوسيطات. على سبيل المثال، في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، تكون قيمة uri_path هي /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. إذا تم تعيينها إلى true، تتم إعادة تقييم مخطط مسار 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:

لقطة شاشة تعرض إجراء إزالة المنفذ.

تعديل عنوان 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لتعيين اسم المضيف لمطابقة الطلب الأصلي.

    لقطة شاشة لإجراء تعديل عنوان الموقع.

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

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

عرض شاشة لعنوان أمان.

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

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

لقطة شاشة تعرض إجراء حذف رأس الصفحة.

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

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

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

عرض شاشة يظهر التحقق من وجود إجراء رأس.

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

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

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

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

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

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

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

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

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

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

سيناريو إعادة كتابة عنوان موقع ويب 2-1.

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

سيناريو إعادة كتابة عنوان موقع ويب 2-2.

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

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

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

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

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

القيود

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

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