HTTP-fejlécek és URL-címek átírása az Application Gateway használatával

  • Cikk

Az Application Gateway lehetővé teszi a kérések és válaszok kiválasztott tartalmának újraírását. Ezzel a funkcióval lefordíthatja az URL-címeket, a lekérdezési sztring paramétereit, valamint módosíthatja a kérés- és válaszfejléceket. Emellett feltételeket is megadhat, hogy az URL-cím vagy a megadott fejlécek csak bizonyos feltételek teljesülése esetén legyenek újraírva. Ezek a feltételek a kérelem és a válasz információin alapulnak.

Megjegyzés:

A HTTP-fejléc- és URL-átírási funkciók csak az Application Gateway v2 termékváltozatához érhetők el

Támogatott átírási típusok

Kérelem- és válaszfejlécek

A HTTP-fejlécek lehetővé teszik, hogy az ügyfél és a kiszolgáló további információkat adjon át egy kéréssel vagy válaszsal. Ezeknek az élőfejeknek az újraírásával fontos feladatokat hajthat végre, például biztonsági fejlécmezőket adhat hozzá, például HSTS/ X-XSS-Protection, eltávolíthatja a bizalmas információkat felfedő válaszfejmezőket, és eltávolíthatja a portadatokat az X-Forwarded-For fejlécekből.

Az Application Gateway lehetővé teszi HTTP-kérések és válaszfejlécek hozzáadását, eltávolítását vagy frissítését, miközben a kérés- és válaszcsomagok az ügyfél és a háttérkészletek között mozognak.

A kérelem- és válaszfejlécek Az Application Gateway használatával történő újraírásáról itt olvashat.

img

Támogatott fejlécek

A kérések és válaszok összes fejlécét átírhatja a Csatlakozás ion és a Frissítés fejlécek kivételével. Az Application Gateway használatával egyéni fejléceket is létrehozhat, és hozzáadhatja őket az azon keresztül irányított kérésekhez és válaszokhoz.

URL-elérési út és lekérdezési sztring

Az Application Gateway URL-átírási funkciójával a következőket teheti:

  • Írja át a kérelem URL-címének állomásnevét, elérési útját és lekérdezési sztringét

  • Válassza ki, hogy egy figyelőre vonatkozó összes kérés URL-címét át szeretné írni, vagy csak azokat a kéréseket, amelyek megfelelnek a megadott feltételeknek. Ezek a feltételek a kérelem tulajdonságain (kérelemfejlécen és kiszolgálóváltozókon) alapulnak.

  • Válassza ki a kérés átirányítását (válassza ki a háttérkészletet) az eredeti VAGY az újraírt URL-cím alapján

Ha tudni szeretné, hogyan írhatja át az URL-címet az Application Gateway használatával az Azure Portalon, tekintse meg itt.

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

Műveletek átírása

Átírási műveletekkel megadhatja az átírni kívánt URL-címeket, kérésfejléceket vagy válaszfejléceket, valamint azt az új értéket, amelybe át szeretné írni őket. Egy URL- vagy egy új vagy meglévő fejléc értéke az alábbi típusú értékekre állítható be:

  • SMS
  • Kérelem fejléce. A kérelem fejlécének megadásához a következő szintaxist kell használnia: {http_req_headerName}
  • Válaszfejléc. Válaszfejléc megadásához a következő szintaxist kell használnia: {http_resp_headerName}
  • Kiszolgálóváltozó. Kiszolgálóváltozó megadásához a(z) {var_serverVariable} szintaxist kell használnia. A támogatott kiszolgálóváltozók listájának megtekintése
  • Szöveg, kérelemfejléc, válaszfejléc és kiszolgálóváltozó kombinációja.

Feltételek újraírása

A HTTP-kérések és -válaszok tartalmának kiértékelésére és újraírására csak egy vagy több feltétel teljesülése esetén használhat újraírási feltételeket, opcionális konfigurációt. Az Application Gateway az alábbi típusú változókat használja a kérések és válaszok tartalmának kiértékeléséhez:

  • HTTP-fejlécek a kérelemben
  • HTTP-fejlécek a válaszban
  • Application Gateway-kiszolgálóváltozók

Feltétel használatával kiértékelheti, hogy egy adott változó jelen van-e, egy adott változó megfelel-e egy adott értéknek, vagy egy adott változó megfelel-e egy adott mintának.

Mintaegyezés

Az Application Gateway normál kifejezéseket használ a feltételben szereplő mintaegyeztetéshez. A feltételek írásakor normál kifejezéssel (RE2) kompatibilis kifejezéseket kell használnia. Ha az Application Gateway webalkalmazási tűzfalát (WAF) a 3.1-s vagy korábbi alapvető szabálykészlettel futtatja, problémákat tapasztalhat a Perl-kompatibilis reguláris kifejezések (PCRE) használatakor a lookahead és a lookbehind (negatív vagy pozitív) állítások használatakor.

Elfog

Ha később használni szeretné az alsztringeket, zárójeleket helyezzen el a regex definícióban szereplő feltételnek megfelelő alpatter körül. Az első zárójelpár az alsztringet 1-ben, a másodikat a 2-ben tárolja, és így tovább. Tetszőleges számú zárójelet használhat; A Perl csak több számozott változót határoz meg, hogy ezeket a rögzített sztringeket képviselje. Néhány példa a ref-ből:

  • (\d) (\d) # Két számjegy egyeztetése, rögzítése az 1. és a 2. csoportba

  • (\d+) # Egy vagy több számjegy egyeztetése, mind rögzítése az 1. csoportba

  • (\d)+ # Egy számjegy egy vagy több alkalommal való egyeztetése, az utolsó rögzítése az 1. csoportba

Megjegyzés:

A minta előtagjának és utótagjának / használata nem adható meg a mintában az értéknek megfelelően. A (\d)(\d) például két számjegynek felel meg. A /(\d)(\d)/ nem egyezik két számjegyből.

A rögzítés után a műveletkészletben a következő formátumban hivatkozhat rájuk:

  • A kérelemfejléc rögzítéséhez a(z) {http_req_headerName_groupNumber} parancsot kell használnia. Például: {http_req_User-Agent_1} vagy {http_req_User-Agent_2}
  • Válaszfej rögzítéséhez a(z) {http_resp_headerName_groupNumber} parancsot kell használnia. Például: {http_resp_Location_1} vagy {http_resp_Location_2}
  • Kiszolgálóváltozók esetén a(z) {var_serverVariableName_groupNumber} függvényt kell használnia. Például: {var_uri_path_1} vagy {var_uri_path_2}

Megjegyzés:

A feltételváltozó esetének meg kell egyeznie a rögzítési változó esetével. Ha például a feltételváltozó user-agent, akkor a rögzítési változónak a User-Agent (azaz {http_req_User-Agent_2}) változónak kell lennie. Ha a feltételváltozó felhasználóügynökként van definiálva, a rögzítési változónak felhasználói ügynökhöz (például {http_req_user-agent_2}) kell lennie.

Ha a teljes értéket szeretné használni, ne említse meg a számot. Egyszerűen használja a(z) {http_req_headerName} formátumot stb. a GroupNumber nélkül.

Kiszolgálóváltozók

Az Application Gateway kiszolgálóváltozókkal tárolja a kiszolgálóval, az ügyféllel való kapcsolattal és a kapcsolatra vonatkozó aktuális kéréssel kapcsolatos hasznos információkat. A tárolt információk közé tartozik például az ügyfél IP-címe és a webböngésző típusa. A kiszolgálóváltozók dinamikusan változnak, például új lap betöltésekor vagy űrlap közzétételekor. Ezekkel a változókkal kiértékelheti az újraírási feltételeket és átírhatja a fejléceket. Ha a kiszolgálóváltozók értékét szeretné használni az élőfejek átírásához, meg kell adnia ezeket a változókat a(z) {var_serverVariableName} szintaxisban.

Az Application Gateway a következő kiszolgálóváltozókat támogatja:

Változó neve Leírás
add_x_forwarded_for_proxy Az X-Forwarded-For ügyfélkérelmet tartalmazó fejlécmező a client_ip változóval (lásd a táblázat későbbi részében) hozzáfűzve IP1, IP2, IP3 stb. formátumban. Ha az X-Forwarded-For mező nem szerepel az ügyfélkérés fejlécében, a add_x_forwarded_for_proxy változó egyenlő a $client_ip változóval. Ez a változó különösen akkor hasznos, ha az Application Gateway által beállított X-Forwarded-For fejlécet szeretné újraírni, hogy a fejléc csak az IP-címet tartalmazza a portinformációk nélkül.
ciphers_supported Az ügyfél által támogatott titkosítások listája.
ciphers_used A létrehozott TLS-kapcsolathoz használt titkosítási sztring.
client_ip Annak az ügyfélnek az IP-címe, ahonnan az Application Gateway megkapta a kérést. Ha az Application Gateway és a kiinduló ügyfél előtt fordított proxy van, client_ip a fordított proxy IP-címét adja vissza.
client_port Az ügyfélport.
client_tcp_rtt Információk az ügyfél TCP-kapcsolatáról. Az TCP_INFO szoftvercsatornát támogató rendszereken érhető el.
client_user HTTP-hitelesítés használata esetén a hitelesítéshez megadott felhasználónév.
házigazda Ebben az elsőbbségi sorrendben: a kérelemsor állomásneve, a Gazdagép kérelem fejlécmezőjének állomásneve vagy a kérésnek megfelelő kiszolgálónév. Példa: A kérelemben http://contoso.com:8080/article.aspx?id=123&title=fabrikama gazdagép értéke a következő lesz: contoso.com
cookie_name A név cookie.
http_method Az URL-kérés létrehozásához használt módszer. Például GET vagy POST.
http_status A munkamenet állapota. Például 200, 400 vagy 403.
http_version A kérelem protokollja. Általában HTTP/1.0, HTTP/1.1 vagy HTTP/2.0.
query_string A kért URL-cím "?" elemét követő változó-érték párok listája. Példa: A kérelemben http://contoso.com:8080/article.aspx?id=123&title=fabrikamquery_string érték lesz id=123&title=fabrikam
received_bytes A kérelem hossza (beleértve a kérelemsort, az élőfejet és a kérelem törzsét).
request_query A kérelemsor argumentumai.
request_scheme A kérelemséma: http vagy https.
request_uri A teljes eredeti kérelem URI-ja (argumentumokkal). Példa: a kérelemben http://contoso.com:8080/article.aspx?id=123&title=fabrikam*request_uri érték lesz /article.aspx?id=123&title=fabrikam
sent_bytes Az ügyfélnek küldött bájtok száma.
server_port A kérést elfogadó kiszolgáló portja.
ssl_connection_protocol A létrehozott TLS-kapcsolat protokollja.
ssl_enabled "Be", ha a kapcsolat TLS módban működik. Ellenkező esetben egy üres sztring.
uri_path A webügyfél által elérni kívánt gazdagép adott erőforrását azonosítja. Ez a kérelem URI-jának argumentumok nélküli része. Példa: A kérelemben http://contoso.com:8080/article.aspx?id=123&title=fabrikamuri_path érték lesz /article.aspx

Mutual authentication server variables

Az Application Gateway a következő kiszolgálóváltozókat támogatja a kölcsönös hitelesítési forgatókönyvekhez. Ezeket a kiszolgálóváltozókat ugyanúgy használja, mint a többi kiszolgálóváltozót.

Változó neve Leírás
client_certificate Az ügyféltanúsítvány PEM formátumban egy létrehozott SSL-kapcsolathoz.
client_certificate_end_date Az ügyféltanúsítvány záró dátuma.
client_certificate_fingerprint Az ügyféltanúsítvány SHA1 ujjlenyomata egy létrehozott SSL-kapcsolathoz.
client_certificate_issuer A létrehozott SSL-kapcsolat ügyféltanúsítványának "kiállító DN" sztringje.
client_certificate_serial A létrehozott SSL-kapcsolat ügyféltanúsítványának sorozatszáma.
client_certificate_start_date Az ügyféltanúsítvány kezdő dátuma.
client_certificate_subject A létrehozott SSL-kapcsolat ügyféltanúsítványának "tulajdonos DN" sztringje.
client_certificate_verification Az ügyféltanúsítvány-ellenőrzés eredménye: SUCCESS, FAILED:<reason> vagy NONE, ha egy tanúsítvány nem volt jelen.

Konfiguráció újraírása

Az újraírási szabály konfigurálásához létre kell hoznia egy újraírási szabálykészletet, és hozzá kell adnia az újraírási szabály konfigurációját.

Az újraírási szabálykészlet a következőket tartalmazza:

  • Útválasztási szabály társítása kérése: Az újraírási konfiguráció az útválasztási szabályon keresztül van társítva a forrásfigyelőhöz. Alapszintű útválasztási szabály használatakor az átírási konfiguráció egy forrásfigyelőhöz van társítva, és globális fejléc-átírás. Útvonalalapú útválasztási szabály használatakor az újraírási konfiguráció az URL-útvonaltérképen van definiálva. Ebben az esetben csak a hely adott útvonalterületére vonatkozik. Több újraírási csoportot is létrehozhat, és mindegyik újraírási halmazt több figyelőre alkalmazhatja. Egy adott figyelőre azonban csak egy átírási készlet alkalmazható.

  • Feltétel újraírása: Nem kötelező konfigurálás. Az újraírási feltételek kiértékelik a HTTP(S) kéréseinek és válaszainak tartalmát. Az átírási művelet akkor következik be, ha a HTTP(S) kérés vagy válasz megfelel az újraírási feltételnek. Ha egynél több feltételt társít egy művelethez, a művelet csak akkor történik meg, ha az összes feltétel teljesül. Más szóval a művelet egy logikai ÉS művelet.

  • Átírás típusa: Háromféle átírás érhető el:

    • Kérelemfejlécek újraírása
    • Válaszfejlécek újraírása
    • URL-összetevők újraírása
      • URL-elérési út: Az az érték, amelyre az elérési utat át kell írni.
      • URL-lekérdezési sztring: Az az érték, amelyre a lekérdezési sztringet át kell írni.
      • Útvonaltérkép újraértékelése: Annak meghatározására szolgál, hogy az URL-cím útvonaltérképét újra kell-e értékelni. Ha nincs bejelölve, a rendszer az eredeti URL-elérési utat használja az URL-útvonaltérkép elérési útvonalmintájának megfelelőként. Ha igaz értékre van állítva, az URL-cím útvonaltérképét újraértékesíti a rendszer, hogy ellenőrizze az újraírt elérési úttal való egyezést. A kapcsoló engedélyezése segít a kérés átirányításában egy másik háttérkészlethez az újraírás után.

A konfiguráció gyakori buktatóinak újraírása

  • Az "Útvonaltérkép újraértékelése" nem engedélyezett az alapszintű kérés-útválasztási szabályok esetében. Ez egy alapszintű útválasztási szabály végtelen kiértékelési ciklusának megakadályozása.

  • Legalább 1 feltételes újraírási szabálynak vagy 1 újraírási szabálynak kell lennie, amely nem rendelkezik engedélyezve az útvonalalapú útválasztási szabályok "Újraértékelési útvonaltérkép" lehetőségével, hogy megakadályozza az elérési útalapú útválasztási szabály végtelen kiértékelési ciklusát.

  • A bejövő kérések 500-os hibakóddal lesznek lezárva, ha egy hurok dinamikusan jön létre az ügyfélbemenetek alapján. Az Application Gateway továbbra is kiszolgálja az egyéb kéréseket anélkül, hogy az ilyen forgatókönyvek romlanak.

URL-átírás vagy gazdagépfejléc átírása webalkalmazási tűzfallal (WAF_v2 termékváltozat)

Ha konfigurálja az URL-átírást vagy a gazdagép fejlécének újraírását, a WAF-kiértékelés a kérelem fejlécének vagy URL-paramétereinek módosítása után történik (az újraírás után). Ha eltávolítja az URL-átírást vagy a gazdagépfej átírásának konfigurációját az Application Gatewayen, a WAF-kiértékelés a fejléc újraírása (előzetes átírása) előtt megtörténik. Ez a sorrend biztosítja, hogy WAF-szabályok legyenek alkalmazva a háttérkészlet által fogadott végső kérelemre.

Tegyük fel például, hogy a fejléchez a következő fejléc-átírási szabály tartozik – ha a fejléc értéke egyenlő "text/html", akkor írja át az értéket a következőre."image/png""Accept" : "text/html""Accept"

Itt csak a fejléc újraírása konfigurálva van, a WAF-kiértékelés a következőn "Accept" : "text/html"lesz végrehajtva: . Ha azonban az URL-átírást vagy a gazdagép fejlécének újraírását konfigurálja, a WAF-kiértékelés a következőn "Accept" : "image/png"történik: .

A fejléc újraírásának gyakori forgatókönyvei

Portadatok eltávolítása az X-Forwarded-For fejlécből

Az Application Gateway minden kérésbe beszúr egy X-Forwarded-For fejlécet, mielőtt a kéréseket a háttérrendszerbe továbbítja. Ez a fejléc az IP-portok vesszővel tagolt listája. Előfordulhatnak olyan helyzetek, amikor a háttérkiszolgálóknak csak az IP-címeket tartalmazó fejlécekre van szükségük. A fejléc átírásával eltávolíthatja a portinformációkat az X-Forwarded-For fejlécből. Ennek egyik módja, ha a fejlécet a add_x_forwarded_for_proxy kiszolgálóváltozóra állítja. Másik lehetőségként használhatja a client_ip változót is:

Remove port

Átirányítási URL-cím módosítása

Az átirányítási URL-cím módosítása bizonyos körülmények között hasznos lehet. Például: az ügyfeleket eredetileg átirányították egy olyan útvonalra, mint a "/blog", de most a tartalomstruktúra változása miatt a "/updates" címre kell küldeni.

Figyelmeztetés:

Az átirányítási URL-cím módosításának szükségessége néha olyan konfiguráció kontextusában merül fel, amelyben az Application Gateway úgy van konfigurálva, hogy felülbírálja a gazdagépnevet a háttérrendszer felé. A háttérrendszer által látott gazdagépnév ebben az esetben eltér a böngésző által látott gazdagépnévtől. Ebben az esetben az átirányítás nem a megfelelő gazdagépnevet használja. Ez a konfiguráció nem ajánlott.

Az ilyen konfiguráció korlátait és következményeit a fordított proxy és a háttérbeli webalkalmazás közötti eredeti HTTP-gazdagépnév megőrzése című cikkben ismertetjük. Az App Service ajánlott beállítása az App Service Application Gateway-lel való konfigurálása során az "Egyéni tartomány (ajánlott)" című témakör utasításait követi. A hely fejlécének újraírása a válaszon az alábbi példában leírtak szerint kerülő megoldásnak tekintendő, és nem foglalkozik a kiváltó okokkal.

Amikor az app service átirányítási választ küld, ugyanazt a gazdagépnevet használja a válasz helyfejlécében, mint az application gatewaytől kapott kérésben. Így az ügyfél közvetlenül az application gateway (contoso.com/path2) használata helyett közvetlenül contoso.azurewebsites.net/path2 a kérést küldi el. Az application gateway megkerülése nem kívánatos.

Ezt a problémát úgy oldhatja meg, hogy a hely fejlécében lévő állomásnevet az Application Gateway tartománynevére állítja.

A gazdagépnév cseréjének lépései a következők:

  1. Hozzon létre egy újraírási szabályt egy feltétellel, amely kiértékeli, hogy a válaszban szereplő hely fejléce tartalmaz-e azurewebsites.net. Adja meg a mintát (https?):\/\/.*azurewebsites\.net(.*)$.
  2. Műveletet hajthat végre a hely fejlécének újraírásához, hogy az tartalmazza az Application Gateway gazdagépnevét. Ehhez adja meg {http_resp_Location_1}://contoso.com{http_resp_Location_2} a fejléc értékét. Másik lehetőségként a kiszolgálóváltozóval host is beállíthatja a gazdagép nevét az eredeti kérésnek megfelelően.

Modify location header

Biztonsági HTTP-fejlécek implementálása a biztonsági rések elkerülése érdekében

Számos biztonsági rést kijavíthat, ha implementálja a szükséges fejléceket az alkalmazás válaszában. Ezek a biztonsági fejlécek közé tartozik az X-XSS-Protection, a Strict-Transport-Security és a Content-Security-Policy. Az Application Gateway használatával beállíthatja ezeket a fejléceket az összes válaszhoz.

Security header

Nem kívánt fejlécek törlése

Előfordulhat, hogy el szeretné távolítani azokat a fejléceket, amelyek bizalmas információkat fednek fel a HTTP-válaszból. Előfordulhat például, hogy el szeretné távolítani az olyan információkat, mint a háttérkiszolgáló neve, az operációs rendszer vagy a tár adatai. Az Application Gateway használatával eltávolíthatja az alábbi fejléceket:

Deleting header

Élőfej jelenlétének ellenőrzése

Kiértékelhet egy HTTP-kérés vagy válaszfejlécet egy fejléc- vagy kiszolgálóváltozó jelenlétére vonatkozóan. Ez a kiértékelés akkor hasznos, ha csak egy adott fejléc esetén szeretne újraírni egy fejlécet.

Checking presence of a header

Az URL-átírás gyakori forgatókönyvei

Paraméteralapú elérési út kiválasztása

Ha olyan forgatókönyveket szeretne megvalósítani, amelyekben a kérelemben szereplő fejléc, URL-cím vagy lekérdezési sztring értéke alapján szeretné kiválasztani a háttérkészletet, használhatja az URL-átírási képesség és az útvonalalapú útválasztás kombinációját. Ha például van egy vásárlási webhelye, és a termékkategória lekérdezési sztringként van átadva az URL-címben, és a lekérdezési sztring alapján szeretné átirányítani a kérést a háttérrendszerbe, akkor:

1. lépés: Elérésiút-térkép létrehozása az alábbi képen látható módon

URL rewrite scenario 1-1.

2. lépés (a): Hozzon létre egy átírási csoportot, amely 3 újraírási szabálysal rendelkezik:

  • Az első szabály olyan feltétellel rendelkezik, amely ellenőrzi a category=shoes query_string változót, és olyan műveletekkel rendelkezik, amelyek átírják a /listing1 URL-elérési útját, és engedélyezve van az elérési út újraértékelése

  • A második szabály olyan feltétellel rendelkezik, amely ellenőrzi a category=bags query_string változót, és olyan műveletet tartalmaz, amely újraírja a /listing2 URL-elérési útját, és engedélyezve van az elérési út újraértékelése

  • A harmadik szabály olyan feltétellel rendelkezik, amely ellenőrzi a category=accessories query_string változót, és olyan műveletekkel rendelkezik, amelyek átírják a /listing3 URL-elérési útját, és engedélyezve van az elérési út újraértékelése

URL rewrite scenario 1-2.

2. lépés (b): Az újraírási csoport társítása a fenti elérési útalapú szabály alapértelmezett elérési útjával

URL rewrite scenario 1-3.

Most, ha a felhasználó contoso.com/listing?category=any kér, akkor az az alapértelmezett elérési úttal lesz egyeztetve, mivel az elérésiút-térkép egyik útvonalmintája sem (/listing1, /listing2, /listing3) egyezik. Mivel a fenti újraírási csoportot ezzel az elérési úttal társította, a rendszer kiértékeli ezt az újraírási csoportot. Mivel a lekérdezési sztring nem egyezik az átírási csoportban szereplő 3 újraírási szabály egyik feltételével sem, nem történik újraírási művelet, ezért a kérés változatlanul lesz átirányítva az alapértelmezett elérési úthoz (azaz GenericList) társított háttérrendszerhez.

Ha a felhasználó contoso.com/listing?category=shoes kér, akkor ismét az alapértelmezett elérési út lesz megfeleltetve. Ebben az esetben azonban az első szabályban szereplő feltétel egyezik, ezért a rendszer végrehajtja a feltételhez társított műveletet, amely újraírja a /listing1 URL-elérési útját, és újraértékeli az elérési úttérképet. Az elérésiút-térkép újraértékelése után a kérés megfelel a minta /listázás1 útvonalának, és a kérés a mintához társított háttérrendszerhez lesz irányítva, amely a ShoesListBackendPool.

Megjegyzés:

Ez a forgatókönyv bármilyen fejléc- vagy cookie-értékre, URL-címre, lekérdezési sztringre vagy kiszolgálóváltozóra kiterjeszthető a megadott feltételek alapján, és lényegében lehetővé teszi a kérések átirányítását ezen feltételek alapján.

A lekérdezési sztring paramétereinek újraírása az URL-cím alapján

Fontolja meg egy olyan vásárlási webhely forgatókönyvét, ahol a felhasználó látható hivatkozásának egyszerűnek és olvashatónak kell lennie, de a háttérkiszolgálónak szüksége van a lekérdezési sztring paramétereire a megfelelő tartalom megjelenítéséhez.

Ebben az esetben az Application Gateway rögzítheti az URL-ből származó paramétereket, és hozzáadhat lekérdezési sztringkulcs-érték párokat az URL-címből. Tegyük fel például, hogy a felhasználó át szeretné írni, https://www.contoso.com/fashion/shirts hogy https://www.contoso.com/buy.aspx?category=fashion&product=shirtsa következő URL-átírási konfigurációval érhető el.

Feltétel – Ha a kiszolgálóváltozó uri_path megegyezik a mintával /(.+)/(.+)

URL rewrite scenario 2-1.

Művelet – AZ URL-elérési út buy.aspx beállítása és a sztring lekérdezése category={var_uri_path_1}&product={var_uri_path_2}

URL rewrite scenario 2-2.

A fent ismertetett forgatókönyv eléréséhez részletes útmutatót az URL-cím újraírása az Application Gateway használatával az Azure Portal használatával című témakörben talál .

URL-átírás és URL-átirányítás

URL-átírás esetén az Application Gateway újraírja az URL-címet, mielőtt a kérést elküldené a háttérrendszernek. Ez nem módosítja a felhasználók által a böngészőben megjelenő elemet, mert a módosítások el vannak rejtve a felhasználó elől.

URL-átirányítás esetén az Application Gateway átirányítási választ küld az ügyfélnek az új URL-címmel. Ehhez viszont az ügyfélnek újra kell küldenie a kérését az átirányításban megadott új URL-címre. A böngészőben látható URL-cím az új URL-címre frissül.

Rewrite vs Redirect.

Korlátozások

  • Ha egy válasznak több fejléce is van ugyanazzal a névvel, akkor az egyik fejléc értékének újraírása a válasz többi fejlécének elvetését eredményezi. Ez általában a Set-Cookie fejlécnél fordulhat elő, mivel egy válaszban több Set-Cookie-fejléc is szerepelhet. Ilyen eset, ha egy app service-t használ egy application gateway használatával, és cookie-alapú munkamenet-affinitást konfigurál az application gatewayen. Ebben az esetben a válasz két Set-Cookie-fejlécet tartalmaz: az egyiket az app service használja, a másikat például Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net az Application Gateway affinitásához, Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/például. Ebben a forgatókönyvben az egyik Set-Cookie fejléc újraírása a másik Set-Cookie fejléc eltávolítását eredményezheti a válaszból.
  • Az átírások nem támogatottak, ha az Application Gateway úgy van konfigurálva, hogy átirányítsa a kéréseket, vagy egyéni hibaoldalt jelenítsen meg.
  • A kérelemfejlécek neve tartalmazhat alfanumerikus karaktereket és kötőjeleket. A többi karaktert tartalmazó fejlécek neve el lesz vetve, amikor a rendszer kérést küld a háttérbeli célnak.
  • A válaszfejlécek nevei az RFC 7230-ban meghatározott alfanumerikus karaktereket és szimbólumokat tartalmazhatnak.
  • Csatlakozás ion- és frissítésfejléceket nem lehet újraírni
  • Az átírások nem támogatottak a közvetlenül az Application Gatewayről generált 4xx és 5xx válaszok esetében

Következő lépések