Ponowne zapisywanie nagłówków i adresów URL HTTP za pomocą usługi Application Gateway

  • Artykuł

Usługa Application Gateway umożliwia ponowne zapisywanie wybranej zawartości żądań i odpowiedzi. Dzięki tej funkcji można tłumaczyć adresy URL, parametry ciągu zapytania, a także modyfikować nagłówki żądań i odpowiedzi. Umożliwia również dodawanie warunków w celu upewnienia się, że adres URL lub określone nagłówki zostaną przepisane tylko wtedy, gdy zostaną spełnione określone warunki. Te warunki są oparte na informacjach dotyczących żądania i odpowiedzi.

Uwaga

Funkcje ponownego zapisywania nagłówka i adresu URL http są dostępne tylko dla jednostki SKU usługi Application Gateway w wersji 2

Obsługiwane typy ponownego zapisywania

Nagłówki żądań i odpowiedzi

Nagłówki HTTP umożliwiają klientowi i serwerowi przekazywanie dodatkowych informacji z żądaniem lub odpowiedzią. Zapisując te nagłówki ponownie, można wykonać ważne zadania, takie jak dodawanie pól nagłówków związanych z zabezpieczeniami, takich jak HSTS/ X-XSS-Protection, usuwanie pól nagłówka odpowiedzi, które mogą ujawniać poufne informacje i usuwanie informacji o porcie z nagłówków X-Forwarded-For.

Usługa Application Gateway umożliwia dodawanie, usuwanie lub aktualizowanie nagłówków żądań HTTP i odpowiedzi, podczas gdy pakiety żądań i odpowiedzi są przenoszone między pulami klienta i zaplecza.

Aby dowiedzieć się, jak przepisać nagłówki żądań i odpowiedzi za pomocą usługi Application Gateway przy użyciu witryny Azure Portal, zobacz tutaj.

img

Obsługiwane nagłówki

Możesz ponownie napisać wszystkie nagłówki w żądaniach i odpowiedziach, z wyjątkiem nagłówków Połączenie i Uaktualnij. Możesz również użyć bramy aplikacji, aby utworzyć nagłówki niestandardowe i dodać je do żądań i odpowiedzi kierowanych przez nią.

Ścieżka adresu URL i ciąg zapytania

Dzięki możliwości ponownego zapisywania adresów URL w usłudze Application Gateway można wykonywać następujące czynności:

  • Ponowne zapisywanie nazwy hosta, ścieżki i ciągu zapytania adresu URL żądania

  • Wybierz ponowne zapisywanie adresu URL wszystkich żądań na odbiorniku lub tylko tych żądań, które pasują do co najmniej jednego ustawionego warunków. Te warunki są oparte na właściwościach żądania (nagłówek żądania i zmienne serwera).

  • Wybierz kierowanie żądania (wybierz pulę zaplecza) na podstawie oryginalnego adresu URL lub przepisanego adresu URL

Aby dowiedzieć się, jak ponownie napisać adres URL w usłudze Application Gateway przy użyciu witryny Azure Portal, zobacz tutaj.

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

Ponowne zapisywanie akcji

Akcje ponownego zapisywania służą do określania adresu URL, nagłówków żądań lub nagłówków odpowiedzi, do których chcesz ponownie napisać, oraz nową wartość, do której chcesz je ponownie napisać. Wartość adresu URL lub nowego lub istniejącego nagłówka można ustawić na następujące typy wartości:

  • Tekst
  • Nagłówek żądania. Aby określić nagłówek żądania, należy użyć składni {http_req_headerName}
  • Nagłówek odpowiedzi. Aby określić nagłówek odpowiedzi, należy użyć składni {http_resp_headerName}
  • Zmienna serwera. Aby określić zmienną serwera, należy użyć składni {var_serverVariable}. Zobacz listę obsługiwanych zmiennych serwera
  • Kombinacja tekstu, nagłówka żądania, nagłówka odpowiedzi i zmiennej serwera.

Ponowne zapisywanie warunków

Możesz użyć warunków ponownego zapisywania, opcjonalnej konfiguracji, aby ocenić zawartość żądań i odpowiedzi HTTP(S) i wykonać ponowne zapisywanie tylko wtedy, gdy spełnione są co najmniej jedno warunki. Brama aplikacji używa tych typów zmiennych do oceny zawartości żądań i odpowiedzi:

  • Nagłówki HTTP w żądaniu
  • Nagłówki HTTP w odpowiedzi
  • Zmienne serwera usługi Application Gateway

Można użyć warunku, aby ocenić, czy określona zmienna jest obecna, czy określona zmienna pasuje do określonej wartości, czy określona zmienna pasuje do określonego wzorca.

Dopasowanie wzorca

Usługa Application Gateway używa wyrażeń regularnych do dopasowywania wzorców w warunku. Podczas pisania warunków należy używać wyrażeń zgodnych z wyrażeniem regularnym 2 (RE2). Jeśli używasz zapory aplikacji internetowej usługi Application Gateway (WAF) z podstawowym zestawem reguł 3.1 lub starszym, mogą wystąpić problemy podczas korzystania z zgodnych wyrażeń regularnych perl (PCRE) podczas wykonywania zapytań i asercji lookbehind (ujemnych lub dodatnich).

Przechwytywanie

Aby przechwycić podciąg do późniejszego użycia, umieść nawiasy wokół podwzorca zgodnego z definicją wyrażenia regularnego warunku. Pierwsza para nawiasów przechowuje jego podciąg w 1, drugą parę w 2 itd. Możesz użyć tak wielu nawiasów, jak chcesz; Narzędzie Perl po prostu definiuje więcej zmiennych ponumerowanych, aby reprezentować te przechwycone ciągi. Kilka przykładów z odwołania:

  • (\d) (\d) # Dopasuj dwie cyfry, przechwytując je w grupach 1 i 2

  • (\d+) # Dopasuj co najmniej jedną cyfrę, przechwytując je wszystkie w grupie 1

  • (\d)+ # Dopasuj cyfrę co najmniej raz, przechwytując ostatni w grupie 1

Uwaga

Użycie funkcji do prefiksu / i sufiksu wzorca nie powinno być określone w wzorcu, aby dopasować wartość. Na przykład (\d)(\d) będzie odpowiadać dwóm cyfrom. /(\d)(\d)/ nie pasuje do dwóch cyfr.

Po przechwyceniu można odwoływać się do nich w zestawie akcji przy użyciu następującego formatu:

  • W przypadku przechwytywania nagłówka żądania należy użyć elementu {http_req_headerName_groupNumber}. Na przykład {http_req_User-Agent_1} lub {http_req_User-Agent_2}
  • W przypadku przechwytywania nagłówka odpowiedzi należy użyć elementu {http_resp_headerName_groupNumber}. Na przykład {http_resp_Location_1} lub {http_resp_Location_2}
  • W przypadku zmiennej serwera należy użyć elementu {var_serverVariableName_groupNumber}. Na przykład {var_uri_path_1} lub {var_uri_path_2}

Uwaga

Wielkość zmiennej warunku musi odpowiadać wielkości liter zmiennej przechwytywania. Jeśli na przykład moja zmienna warunku to User-Agent, zmienna przechwytywania musi być dla agenta użytkownika (tj. {http_req_User-Agent_2}). Jeśli moja zmienna warunku jest zdefiniowana jako agent użytkownika, zmienna przechwytywania musi być dla agenta użytkownika (tj. {http_req_user-agent_2}).

Jeśli chcesz użyć wartości całkowitej, nie należy wspomnieć o liczbie. Wystarczy użyć formatu {http_req_headerName}, itp. bez wartości groupNumber.

Zmienne serwera

Usługa Application Gateway używa zmiennych serwera do przechowywania przydatnych informacji o serwerze, połączeniu z klientem i bieżącym żądaniu połączenia. Przykłady przechowywanych informacji obejmują adres IP klienta i typ przeglądarki internetowej. Zmienne serwera zmieniają się dynamicznie, na przykład po załadowaniu nowej strony lub opublikowaniu formularza. Te zmienne umożliwiają ocenę warunków ponownego zapisywania i ponownego zapisywania nagłówków. Aby użyć wartości zmiennych serwera do ponownego zapisania nagłówków, należy określić te zmienne w składni {var_serverVariableName}

Usługa Application Gateway obsługuje następujące zmienne serwera:

Nazwa zmiennej opis
add_x_forwarded_for_proxy Pole nagłówka żądania klienta X-Forwarded-For ze zmienną client_ip (zobacz wyjaśnienie w dalszej części tej tabeli) dołączone do niego w formacie IP1, IP2, IP3 itd. Jeśli pole X-Forwarded-For nie znajduje się w nagłówku żądania klienta, zmienna add_x_forwarded_for_proxy jest równa zmiennej $client_ip . Ta zmienna jest szczególnie przydatna, gdy chcesz ponownie napisać nagłówek X-Forwarded-For ustawiony przez usługę Application Gateway, aby nagłówek zawierał tylko adres IP bez informacji o porcie.
ciphers_supported Lista szyfrów obsługiwanych przez klienta.
ciphers_used Parametry szyfrowania używane na potrzeby ustanowionego połączenia TLS.
client_ip Adres IP klienta, z którego brama aplikacji odebrała żądanie. Jeśli istnieje zwrotny serwer proxy przed bramą aplikacji i klientem źródłowym, client_ip zwróci adres IP zwrotnego serwera proxy.
client_port Port klienta.
client_tcp_rtt Informacje o połączeniu TCP klienta. Dostępne w systemach obsługujących opcję gniazda TCP_INFO.
client_user Gdy jest używane uwierzytelnianie HTTP, nazwa użytkownika podana do uwierzytelniania.
host W tej kolejności pierwszeństwa: nazwa hosta z wiersza żądania, nazwa hosta z pola nagłówka żądania hosta lub nazwa serwera pasującego do żądania. Przykład: W żądaniu http://contoso.com:8080/article.aspx?id=123&title=fabrikamwartość hosta będzie wynosić contoso.com
nazwa cookie_ Nazwa pliku cookie.
http_method Metoda użyta do wykonania żądania adresu URL. Na przykład GET lub POST.
http_status Stan sesji. Na przykład 200, 400 lub 403.
http_version Protokół żądania. Zazwyczaj HTTP/1.0, HTTP/1.1 lub HTTP/2.0.
Query_string Lista par zmiennych/wartości, które są zgodne z "?" w żądanym adresie URL. Przykład: w żądaniu http://contoso.com:8080/article.aspx?id=123&title=fabrikamquery_string wartość będzie mieć wartość id=123&title=fabrikam
received_bytes Długość żądania (w tym wiersz żądania, nagłówek i treść żądania).
request_query Argumenty w wierszu żądania.
request_scheme Schemat żądania: http lub https.
request_uri Pełny oryginalny identyfikator URI żądania (z argumentami). Przykład: w żądaniu http://contoso.com:8080/article.aspx?id=123&title=fabrikam*request_uri wartością będzie /article.aspx?id=123&title=fabrikam
sent_bytes Liczba bajtów wysłanych do klienta.
server_port Port serwera, który zaakceptował żądanie.
ssl_connection_protocol Protokół ustanowionego połączenia TLS.
ssl_enabled "Włączone", jeśli połączenie działa w trybie TLS. W przeciwnym razie pusty ciąg.
uri_path Identyfikuje określony zasób na hoście, do którego klient internetowy chce uzyskać dostęp. Jest to część identyfikatora URI żądania bez argumentów. Przykład: w żądaniu http://contoso.com:8080/article.aspx?id=123&title=fabrikamwartość uri_path będzie /article.aspx

Zmienne serwera uwierzytelniania wzajemnego

Usługa Application Gateway obsługuje następujące zmienne serwera dla scenariuszy wzajemnego uwierzytelniania. Użyj tych zmiennych serwera w taki sam sposób jak powyżej z innymi zmiennymi serwera.

Nazwa zmiennej opis
client_certificate Certyfikat klienta w formacie PEM dla ustanowionego połączenia SSL.
client_certificate_end_date Data zakończenia certyfikatu klienta.
client_certificate_fingerprint Odcisk palca SHA1 certyfikatu klienta dla ustanowionego połączenia SSL.
client_certificate_issuer Parametry "issuer DN" certyfikatu klienta dla ustanowionego połączenia SSL.
client_certificate_serial Numer seryjny certyfikatu klienta dla ustanowionego połączenia SSL.
client_certificate_start_date Data rozpoczęcia certyfikatu klienta.
client_certificate_subject Parametry "subject DN" certyfikatu klienta dla ustanowionego połączenia SSL.
client_certificate_verification Wynik weryfikacji certyfikatu klienta: SUCCESS, FAILED:<reason> lub NONE, jeśli certyfikat nie był obecny.

Ponowne zapisywanie konfiguracji

Aby skonfigurować regułę ponownego zapisywania, należy utworzyć zestaw reguł ponownego zapisywania i dodać w niej konfigurację reguły ponownego zapisywania.

Zestaw reguł ponownego zapisywania zawiera:

  • Skojarzenie reguły routingu żądań: konfiguracja ponownego zapisywania jest skojarzona z odbiornikiem źródłowym za pośrednictwem reguły routingu. W przypadku korzystania z podstawowej reguły routingu konfiguracja ponownego zapisywania jest skojarzona z odbiornikiem źródłowym i jest globalnym zapisywaniem nagłówka. W przypadku korzystania z reguły routingu opartej na ścieżkach konfiguracja ponownego zapisywania jest definiowana na mapie ścieżek URL. W takim przypadku ma zastosowanie tylko do określonego obszaru ścieżki witryny. Można utworzyć wiele zestawów ponownego zapisywania i zastosować każdy ponowny zapis ustawiony na wiele odbiorników. Można jednak zastosować tylko jeden ponowny zapis ustawiony na określony odbiornik.

  • Warunek ponownego zapisywania: jest to opcjonalna konfiguracja. Ponowne zapisywanie warunków ocenia zawartość żądań i odpowiedzi HTTP(S). Akcja ponownego zapisywania zostanie wykonana, jeśli żądanie HTTP(S) lub odpowiedź jest zgodne z warunkiem ponownego zapisywania. Jeśli skojarzysz więcej niż jeden warunek z akcją, akcja występuje tylko wtedy, gdy zostaną spełnione wszystkie warunki. Innymi słowy, operacja jest operacją logiczną AND.

  • Typ ponownego zapisywania: dostępne są 3 typy ponownego zapisywania:

    • Ponowne zapisywanie nagłówków żądań
    • Ponowne zapisywanie nagłówków odpowiedzi
    • Ponowne zapisywanie składników adresu URL
      • Ścieżka adresu URL: wartość, do której ma zostać przepisana ścieżka.
      • Ciąg zapytania adresu URL: wartość, do której ma zostać przepisany ciąg zapytania.
      • Ponownie oceń mapę ścieżki: służy do określania, czy mapa ścieżek URL ma zostać ponownie oszacowana, czy nie. Jeśli zachowano niezaznaczone, oryginalna ścieżka adresu URL będzie używana do dopasowania wzorca ścieżki w mapie ścieżki adresu URL. Jeśli ustawiono wartość true, mapa ścieżki adresu URL zostanie ponownie zwalczona, aby sprawdzić dopasowanie ze ścieżką przepisaną. Włączenie tego przełącznika pomaga w rozsyłaniu żądania do innej puli zaplecza po ponownym zapisie.

Ponowne zapisywanie typowych pułapek konfiguracji

  • Włączenie opcji "Ponowne ocenianie mapy ścieżek" nie jest dozwolone dla podstawowych reguł routingu żądań. Zapobiega to nieskończonej pętli ewaluacyjnej dla podstawowej reguły routingu.

  • Musi istnieć co najmniej 1 reguła ponownego zapisywania warunkowego lub 1 reguła ponownego zapisywania, która nie ma włączonej opcji "Ponowne ocenianie mapy ścieżek" dla reguł routingu opartego na ścieżkach, aby zapobiec nieskończonej pętli ewaluacyjnej dla reguły routingu opartej na ścieżkach.

  • Żądania przychodzące zostaną zakończone kodem błędu 500 w przypadku, gdy pętla jest tworzona dynamicznie na podstawie danych wejściowych klienta. Usługa Application Gateway będzie nadal obsługiwać inne żądania bez pogorszenia w takim scenariuszu.

Używanie ponownego zapisywania adresu URL lub ponownego zapisywania nagłówka hosta za pomocą zapory aplikacji internetowej (jednostka SKU WAF_v2)

Podczas konfigurowania ponownego zapisywania adresu URL lub ponownego zapisywania nagłówka hosta ocena zapory aplikacji internetowej zostanie wykonana po modyfikacji nagłówka żądania lub parametrów adresu URL (po ponownym zapisaniu). A po usunięciu ponownego zapisywania adresu URL lub ponownego zapisywania nagłówka hosta w usłudze Application Gateway ocena zapory aplikacji internetowej zostanie wykonana przed ponownym zapisem nagłówka (wstępnego ponownego zapisywania). Ta kolejność gwarantuje, że reguły zapory aplikacji internetowej są stosowane do końcowego żądania, które zostanie odebrane przez pulę zaplecza.

Załóżmy na przykład, że masz następującą regułę ponownego zapisywania nagłówka dla nagłówka "Accept" : "text/html" — jeśli wartość nagłówka "Accept" jest równa "text/html", zapisz ponownie wartość na "image/png".

W tym miejscu tylko po skonfigurowaniu ponownego zapisywania nagłówka ocena zapory aplikacji internetowej zostanie wykonana na stronie "Accept" : "text/html". Jednak podczas konfigurowania ponownego zapisywania adresu URL lub ponownego zapisywania nagłówka hosta ocena zapory aplikacji internetowej zostanie wykonana w systemie "Accept" : "image/png".

Typowe scenariusze ponownego zapisywania nagłówka

Usuwanie informacji o porcie z nagłówka X-Forwarded-For

Usługa Application Gateway wstawia nagłówek X-Forwarded-For do wszystkich żądań przed przekazaniem żądań do zaplecza. Ten nagłówek jest rozdzielaną przecinkami listą portów IP. Mogą istnieć scenariusze, w których serwery zaplecza muszą zawierać tylko nagłówki zawierające adresy IP. Aby usunąć informacje o porcie z nagłówka X-Forwarded-For, możesz użyć ponownego zapisywania nagłówka. Jednym ze sposobów wykonania tej czynności jest ustawienie nagłówka na zmienną serwera add_x_forwarded_for_proxy. Alternatywnie możesz również użyć zmiennej client_ip:

Remove port

Modyfikowanie adresu URL przekierowania

Modyfikacja adresu URL przekierowania może być przydatna w pewnych okolicznościach. Na przykład: klienci zostali pierwotnie przekierowani do ścieżki takiej jak "/blog", ale teraz powinni zostać wysłani do "/updates" ze względu na zmianę struktury zawartości.

Ostrzeżenie

Potrzeba zmodyfikowania adresu URL przekierowania czasami pojawia się w kontekście konfiguracji, w której usługa Application Gateway jest skonfigurowana do zastąpienia nazwy hosta w kierunku zaplecza. Nazwa hosta widoczna w zapleczu różni się w takim przypadku od nazwy hosta widocznej w przeglądarce. W takiej sytuacji przekierowanie nie będzie używać poprawnej nazwy hosta. Ta konfiguracja nie jest zalecana.

Ograniczenia i implikacje takiej konfiguracji opisano w artykule Zachowaj oryginalną nazwę hosta HTTP między zwrotnym serwerem proxy a aplikacją internetową zaplecza. Zalecaną konfiguracją usługi App Service jest wykonanie instrukcji dotyczących "Domena niestandardowa (zalecana)" w temacie Konfigurowanie usługi App Service z usługą Application Gateway. Ponowne zapisywanie nagłówka lokalizacji w odpowiedzi zgodnie z opisem w poniższym przykładzie powinno być traktowane jako obejście problemu i nie dotyczy głównej przyczyny.

Gdy usługa App Service wysyła odpowiedź przekierowania, używa tej samej nazwy hosta w nagłówku lokalizacji odpowiedzi co w żądaniu odbieranym z bramy aplikacji. W związku z tym klient wyśle żądanie bezpośrednio do contoso.azurewebsites.net/path2 zamiast przechodzić przez bramę aplikacji (contoso.com/path2). Pomijanie bramy aplikacji nie jest pożądane.

Ten problem można rozwiązać, ustawiając nazwę hosta w nagłówku lokalizacji na nazwę domeny bramy aplikacji.

Poniżej przedstawiono kroki zastępowania nazwy hosta:

  1. Utwórz regułę ponownego zapisywania z warunkiem, który ocenia, czy nagłówek lokalizacji w odpowiedzi zawiera azurewebsites.net. Wprowadź wzorzec (https?):\/\/.*azurewebsites\.net(.*)$.
  2. Wykonaj akcję, aby ponownie zapisać nagłówek lokalizacji, tak aby miał nazwę hosta bramy aplikacji. Zrób to, wprowadzając {http_resp_Location_1}://contoso.com{http_resp_Location_2} jako wartość nagłówka. Alternatywnie możesz również użyć zmiennej host serwera, aby ustawić nazwę hosta tak, aby odpowiadała oryginalnemu żądaniu.

Modify location header

Implementowanie nagłówków HTTP zabezpieczeń w celu zapobiegania lukom w zabezpieczeniach

Możesz naprawić kilka luk w zabezpieczeniach, implementując niezbędne nagłówki w odpowiedzi aplikacji. Te nagłówki zabezpieczeń obejmują X-XSS-Protection, Strict-Transport-Security i Content-Security-Policy. Za pomocą usługi Application Gateway można ustawić te nagłówki dla wszystkich odpowiedzi.

Security header

Usuwanie niechcianych nagłówków

Możesz usunąć nagłówki, które ujawniają poufne informacje z odpowiedzi HTTP. Możesz na przykład usunąć informacje, takie jak nazwa serwera zaplecza, system operacyjny lub szczegóły biblioteki. Za pomocą bramy aplikacji można usunąć następujące nagłówki:

Deleting header

Sprawdzanie obecności nagłówka

Możesz ocenić żądanie HTTP lub nagłówek odpowiedzi pod kątem obecności nagłówka lub zmiennej serwera. Ta ocena jest przydatna, gdy chcesz ponownie napisać nagłówek tylko wtedy, gdy istnieje określony nagłówek.

Checking presence of a header

Typowe scenariusze ponownego zapisywania adresów URL

Wybór ścieżki opartej na parametrach

Aby wykonać scenariusze, w których chcesz wybrać pulę zaplecza na podstawie wartości nagłówka, części adresu URL lub ciągu zapytania w żądaniu, możesz użyć kombinacji funkcji ponownego zapisywania adresów URL i routingu opartego na ścieżkach. Jeśli na przykład masz witrynę internetową zakupów, a kategoria produktu jest przekazywana jako ciąg zapytania w adresie URL i chcesz kierować żądanie do zaplecza na podstawie ciągu zapytania, wówczas:

Krok 1. Tworzenie mapy ścieżki, jak pokazano na poniższej ilustracji

URL rewrite scenario 1-1.

Krok 2 (a): Utwórz zestaw ponownego zapisywania, który ma 3 reguły ponownego zapisywania:

  • Pierwsza reguła ma warunek, który sprawdza zmienną query_string category =shoes i ma akcję, która ponownie zapisuje ścieżkę adresu URL na /listing1 i ma włączoną mapę ścieżki ponownej oceny

  • Druga reguła ma warunek, który sprawdza zmienną query_string dla kategorii=torby i ma akcję, która ponownie zapisuje ścieżkę adresu URL na /listing2 i ma włączoną mapę ścieżki ponownej oceny

  • Trzecia reguła ma warunek, który sprawdza zmienną query_string dla kategorii=akcesoria i ma akcję, która ponownie zapisuje ścieżkę adresu URL na /listing3 i ma włączoną mapę ścieżki ponownej oceny

URL rewrite scenario 1-2.

Krok 2 (b): Skojarzenie tego ponownego zapisywania z domyślną ścieżką powyższej reguły opartej na ścieżkach

URL rewrite scenario 1-3.

Teraz, jeśli użytkownik żąda contoso.com/listing?category=any, zostanie on dopasowany do ścieżki domyślnej, ponieważ żadne wzorce ścieżek na mapie ścieżki (/listing1, /listing2, /listing3) będą zgodne. Ponieważ powyższe przepisanie zostało skojarzone z tą ścieżką, ten zestaw ponownego zapisywania zostanie oceniony. Ponieważ ciąg zapytania nie będzie zgodny z warunkiem w żadnym z 3 reguł ponownego zapisywania w tym zestawie ponownego zapisywania, nie zostanie utworzona żadna akcja ponownego zapisywania, a zatem żądanie zostanie przekierowane bez zmian do zaplecza skojarzonego ze ścieżką domyślną (czyli GenericList).

Jeśli użytkownik zażąda contoso.com/listing?category=shoes, zostanie ponownie dopasowana ścieżka domyślna. Jednak w tym przypadku warunek w pierwszej regule będzie zgodny i w związku z tym akcja skojarzona z warunkiem zostanie wykonana, co spowoduje ponowne zapisywanie ścieżki adresu URL do /listing1 i ponownej oceny ścieżki-mapy. Gdy ścieżka-mapa zostanie ponownie zwalczona, żądanie będzie teraz zgodne ze ścieżką skojarzoną ze wzorcem /listing1 , a żądanie zostanie skierowane do zaplecza skojarzonego z tym wzorcem, czyli ShoesListBackendPool.

Uwaga

Ten scenariusz można rozszerzyć na dowolną wartość nagłówka lub pliku cookie, ścieżkę adresu URL, ciąg zapytania lub zmienne serwera na podstawie zdefiniowanych warunków i zasadniczo umożliwia kierowanie żądań na podstawie tych warunków.

Ponowne zapisywanie parametrów ciągu zapytania na podstawie adresu URL

Rozważmy scenariusz witryny internetowej zakupów, w którym widoczny link użytkownika powinien być prosty i czytelny, ale serwer zaplecza potrzebuje parametrów ciągu zapytania, aby wyświetlić właściwą zawartość.

W takim przypadku usługa Application Gateway może przechwytywać parametry z adresu URL i dodawać pary klucz-wartość ciągu zapytania z tych z adresu URL. Załóżmy na przykład, że użytkownik chce ponownie napisać polecenie , https://www.contoso.com/fashion/shirtshttps://www.contoso.com/buy.aspx?category=fashion&product=shirtsmożna to osiągnąć za pomocą następującej konfiguracji ponownego zapisywania adresów URL.

Warunek — jeśli zmienna uri_path serwera jest równa wzorzec /(.+)/(.+)

URL rewrite scenario 2-1.

Akcja — ustaw ścieżkę adresu URL na buy.aspx i ciąg zapytania na category={var_uri_path_1}&product={var_uri_path_2}

URL rewrite scenario 2-2.

Aby zapoznać się z przewodnikiem krok po kroku dotyczącym osiągnięcia opisanego powyżej scenariusza, zobacz Ponowne zapisywanie adresu URL w usłudze Application Gateway przy użyciu witryny Azure Portal

Ponowne zapisywanie adresów URL a przekierowywanie adresów URL

W przypadku ponownego zapisywania adresu URL usługa Application Gateway ponownie zapisuje adres URL przed wysłaniem żądania do zaplecza. Nie spowoduje to zmiany, które użytkownicy widzą w przeglądarce, ponieważ zmiany są ukryte przed użytkownikiem.

W przypadku przekierowania adresu URL usługa Application Gateway wysyła odpowiedź przekierowania do klienta przy użyciu nowego adresu URL. To z kolei wymaga od klienta ponownego wysłanie żądania do nowego adresu URL podanego w przekierowaniu. Adres URL widoczny w przeglądarce zostanie zaktualizowany do nowego adresu URL.

Rewrite vs Redirect.

Ograniczenia

  • Jeśli odpowiedź ma więcej niż jeden nagłówek o tej samej nazwie, ponowne zapisywanie wartości jednego z tych nagłówków spowoduje usunięcie innych nagłówków w odpowiedzi. Zwykle może się to zdarzyć z nagłówkiem Set-Cookie, ponieważ w odpowiedzi może znajdować się więcej niż jeden nagłówek Set-Cookie. Jednym z takich scenariuszy jest użycie usługi App Service z bramą aplikacji i skonfigurowanie koligacji sesji opartej na plikach cookie w bramie aplikacji. W takim przypadku odpowiedź będzie zawierać dwa nagłówki Set-Cookie: jeden używany przez usługę App Service, na przykład: Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net i drugi dla koligacji bramy aplikacji, na przykład Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. Ponowne zapisywanie jednego z nagłówków Set-Cookie w tym scenariuszu może spowodować usunięcie innego nagłówka Set-Cookie z odpowiedzi.
  • Ponowne zapisywanie nie jest obsługiwane, gdy brama aplikacji jest skonfigurowana do przekierowywania żądań lub wyświetlania niestandardowej strony błędu.
  • Nazwy nagłówków żądania mogą zawierać znaki alfanumeryczne i łączniki. Nazwy nagłówków zawierające inne znaki zostaną odrzucone, gdy żądanie zostanie wysłane do obiektu docelowego zaplecza.
  • Nazwy nagłówków odpowiedzi mogą zawierać dowolne znaki alfanumeryczne i określone symbole zgodnie z definicją w dokumencie RFC 7230.
  • Nie można przepisać nagłówków Połączenie i uaktualnień
  • Ponowne zapisywanie nie jest obsługiwane w przypadku odpowiedzi 4xx i 5xx generowanych bezpośrednio z usługi Application Gateway

Następne kroki