HTTP-fejlécek és URL-címek átírása az Application Gateway használatával
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.
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.
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=fabrikam a 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=fabrikam query_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=fabrikam uri_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:
Á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:
- 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(.*)$
. - 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óvalhost
is beállíthatja a gazdagép nevét az eredeti kérésnek megfelelően.
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.
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:
É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.
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
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
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
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=shirts
a 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 /(.+)/(.+)
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}
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.
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