Regenerasi header HTTP dan URL dengan Application Gateway

Application Gateway memungkinkan Anda menulis ulang konten yang dipilih dalam permintaan dan respons. Dengan fitur ini, Anda dapat menerjemahkan URL, parameter string kueri, dan mengubah header permintaan dan respons. Anda juga dapat menambahkan kondisi untuk memastikan bahwa URL atau header yang ditentukan ditulis ulang hanya saat kondisi tertentu terpenuhi. Kondisi tersebut didasarkan pada informasi permintaan dan respons.

Header HTTP dan fitur penulisan ulang URL hanya tersedia untuk SKU Application Gateway v2.

Header permintaan dan respons

Application Gateway memungkinkan Anda menambahkan, menghapus, atau memperbarui header permintaan dan respons HTTP saat paket permintaan dan respons berpindah antara kumpulan klien dan backend. Header HTTP memungkinkan klien dan server meneruskan informasi tambahan dengan permintaan atau respons. Dengan menulis ulang header ini, Anda dapat menyelesaikan tugas penting termasuk:

• Menambahkan bidang header terkait keamanan seperti HSTS dan X-XSS-Protection
• Menghapus bidang header respons yang mungkin mengungkapkan informasi sensitif
• Menghapus informasi port dari header X-Forwarded-For

Anda dapat menulis ulang semua header dalam permintaan dan respons, kecuali untuk Connection header dan Upgrade . Anda juga dapat menggunakan gateway aplikasi untuk membuat header kustom dan menambahkannya ke permintaan dan respons yang dirutekan melaluinya. Untuk mempelajari cara menulis ulang header permintaan dan respons dengan Application Gateway dengan menggunakan portal Microsoft Azure, lihat di sini.

Jalur URL dan untai kueri

Dengan kemampuan regenerasi URL di Application Gateway, Anda dapat:

• Menulis ulang nama host, jalur, dan string kueri URL permintaan

• Pilih untuk menulis ulang URL semua permintaan pada pendengar atau hanya permintaan yang cocok dengan satu atau beberapa kondisi yang Anda tetapkan. Kondisi ini didasarkan pada properti permintaan (header permintaan dan variabel server).

• Memilih untuk merutekan permintaan (memilih kumpulan ujung belakang) berdasarkan URL asli atau URL yang diregenerasi

Untuk mempelajari cara menulis ulang URL dengan Application Gateway dengan menggunakan portal Microsoft Azure, lihat di sini.

Memahami penulisan ulang di Application Gateway

Set penulisan ulang adalah kumpulan aturan perutean, kondisi, dan tindakan.

• Asosiasi aturan perutean permintaan: Konfigurasi penulisan ulang diasosiasikan dengan pendengar sumber melalui aturan peruteannya. Saat Anda menggunakan aturan perutean dari jenis Dasar, konfigurasi penulisan ulang terkait dengan pendengarnya dan berfungsi sebagai penulisan ulang global. Saat Anda menggunakan aturan perutean berbasis Jalur, Anda menentukan konfigurasi penulisan ulang sesuai dengan peta jalur URL. Dalam kasus terakhir, ini hanya berlaku untuk area jalur tertentu dari situs. Anda dapat menerapkan set penulisan ulang ke beberapa aturan perutean, tetapi aturan perutean hanya dapat memiliki satu penulisan ulang yang terkait dengannya.

• Kondisi Penulisan Ulang: Konfigurasi ini bersifat opsional. Berdasarkan kondisi yang Anda tentukan, Application Gateway mengevaluasi konten permintaan dan respons HTTP.S. "Tindakan penulisan ulang" berikutnya terjadi jika permintaan atau respons HTTP cocok dengan kondisi ini. Jika anda menghubungkan lebih dari satu kondisi dengan sebuah tindakan, tindakan tersebut hanya terjadi ketika semua kondisi terpenuhi. Dengan kata lain, ini adalah operasi "AND" logika. Anda dapat menggunakan kondisi penulisan ulang untuk mengevaluasi konten permintaan dan respons HTTP. Konfigurasi opsional ini memungkinkan Anda untuk melakukan penulisan ulang hanya ketika satu atau beberapa kondisi terpenuhi. Gateway aplikasi menggunakan jenis variabel berikut untuk mengevaluasi konten permintaan dan respons:

  Anda bisa memilih jenis berikut untuk mencari kondisi:

  • Header HTTP (Permintaan dan Respons)
  • Variabel Server yang Didukung

  Kondisi memungkinkan Anda mengevaluasi apakah header atau variabel tertentu ada dengan mencocokkan nilainya melalui teks atau pola Regex. Untuk konfigurasi penulisan ulang tingkat lanjut, Anda juga dapat mengambil nilai variabel header atau server untuk digunakan nanti di bawah Tindakan Penulisan Ulang. Pelajari selengkapnya tentang pola dan pengambilan.

• Tindakan Penulisan Ulang: Set tindakan penulisan ulang memungkinkan Anda menulis ulang header (permintaan atau respons) atau komponen URL.

  Tindakan dapat memiliki jenis nilai berikut atau kombinasinya:

  • Teks.
  • Nilai header permintaan - Untuk menggunakan nilai header permintaan yang diambil, tentukan sintaks sebagai {http_req_headerName}.
  • Nilai header respons - Untuk menggunakan nilai header respons yang diambil dari kondisi sebelumnya, tentukan sintaks sebagai {http_resp_headerName}. Blok Tindakan Penulisan Ulang juga mendukung bidang "Pencocokan Nilai Header" untuk header Set-Cookie. Bidang opsional ini memungkinkan Anda mencocokkan dan mengambil nilai header tertentu saat beberapa header Set-Cookie dengan nama yang sama ada. Untuk memanipulasi nilai cookie tertentu yang diambil, Anda kemudian dapat menggunakan {capt_header_value_matcher}. Pelajari selengkapnya tentang pengambilan di bawah Kumpulan tindakan.
  • Variabel server - Untuk menggunakan variabel server, tentukan sintaks sebagai {var_serverVariable}. Daftar variabel Server yang didukung.

Catatan

Penggunaan bidang Pencocok Nilai Header {capt_header_value_matcher} saat ini tidak didukung melalui portal. Oleh karena itu, Anda perlu menggunakan metode non-portal untuk operasi PUT apa pun jika Anda menggunakan bidang ini.

Saat Anda menggunakan tindakan untuk menulis ulang URL, operasi berikut ini didukung:

• Jalur URL: Nilai baru yang akan ditetapkan sebagai jalur.
• String Kueri URL: Nilai baru tempat string kueri harus ditulis ulang.
• Mengevaluasi ulang peta jalur: Tentukan apakah peta jalur URL harus dievaluasi ulang setelah ditulis ulang. Jika Anda tidak mencentang opsi ini, jalur URL asli digunakan untuk mencocokkan pola jalur di peta jalur URL. Jika Anda mengatur opsi ini ke true, peta jalur URL dievaluasi kembali untuk memeriksa kecocokan dengan jalur yang ditulis ulang. Mengaktifkan tombol ini membantu dalam merutekan permintaan ke regenerasi pos kumpulan ujung belakang.

Pencocokan dan pencocokan pola

Application Gateway mendukung pencocokan pola dalam Kondisi dan Tindakan. Dalam opsi Tindakan, ini mendukung pencocokan pola dan menangkap hanya untuk header tertentu.

Pencocokan pola

Application Gateway menggunakan ekspresi reguler untuk pencocokan pola. Gunakan ekspresi kompatibel Regular Expression 2 (RE2) saat menulis sintaks pencocokan pola Anda.

Anda dapat menggunakan pencocokan pola di bawah Kondisi dan Tindakan.

• Kondisi: Gunakan pengaturan ini untuk mencocokkan nilai untuk Variabel Header atau Server. Untuk mencocokkan pola di bawah "Kondisi", gunakan properti "pola".
• Tindakan: Pencocokan pola di bawah Set Tindakan hanya tersedia untuk header respons Set-Cookie. Untuk mencocokkan pola untuk Set-Cookie di bawah tindakan, gunakan HeaderValueMatcher properti . Jika diambil, nilainya dapat digunakan sebagai {capt_header_value_matcher}. Karena mungkin ada beberapa Set-Cookie header, pencocokan pola di sini memungkinkan Anda untuk mencari cookie tertentu. Misalnya, untuk versi agen pengguna tertentu, Anda ingin mengubah ulang header respons set-cookie untuk cookie2 dengan max-age=3600 (satu jam). Dalam hal ini, Anda dapat menggunakan
  • Kondisi - Jenis: Header permintaan, Nama header: agen pengguna, Pola yang cocok: *2.0
  • Tindakan - Tipe penulisan ulang: Header respons, Tipe tindakan: Setel, Nama header: Set-Cookie, Pencocokan nilai header: cookie2=(.*), Nilai header: cookie2={capt_header_value_matcher_1};Max-Age=3600

Catatan

Jika Anda menjalankan Application Gateway Web Application Firewall (WAF) dengan Core Rule Set 3.1 atau versi sebelumnya, Anda mungkin mengalami masalah saat menggunakan Perl Compatible Regular Expressions (PCRE) saat melakukan asersi lookahead dan lookbehind (baik negatif maupun positif).

Sintaks untuk menangkap

Anda dapat menggunakan pola untuk mengambil substring untuk digunakan nanti. Letakkan tanda kurung di sekitar sub-pola dalam definisi regex. Sepasang tanda kurung pertama menyimpan subuntai-nya dalam 1, pasangan kedua dalam 2, dan seterusnya. Anda dapat menggunakan tanda kurung sebanyak yang Anda inginkan. Perl mendefinisikan lebih banyak variabel bernomor untuk mewakili string yang diambil ini. Anda dapat menemukan beberapa contoh dalam panduan pemrograman Perl ini.

• (\d)(\d) # Cocokkan dua digit, menangkapnya ke dalam grup 1 dan 2
• (\d+) # Cocokkan satu atau beberapa digit, menangkap semuanya ke dalam grup 1
• (\d)+ # Cocokkan digit satu atau beberapa kali, menangkap yang terakhir ke dalam grup 1

Setelah diambil, Anda dapat menggunakannya dalam nilai Kumpulan Tindakan menggunakan format berikut:

• Untuk tangkapan header permintaan, Anda harus menggunakan {http_req_headerName_groupNumber}. Misalnya, {http_req_User-Agent_1} atau {http_req_User-Agent_2}
• Untuk tangkapan header respons, Anda harus menggunakan {http_resp_headerName_groupNumber}. Misalnya, {http_resp_Location_1} atau {http_resp_Location_2}. Sedangkan untuk header respons Set-Cookie yang diambil melalui properti "HeaderValueMatcher", Anda harus menggunakan {capt_header_value_matcher_groupNumber}. Misalnya, {capt_header_value_matcher_1} atau {capt_header_value_matcher_2}.
• Untuk variabel server, Anda harus menggunakan {var_serverVariableName_groupNumber}. Misalnya, {var_uri_path_1} atau {var_uri_path_2}

Catatan

• Penggunaan / untuk awalan dan akhiran pola tidak boleh ditentukan dalam pola untuk mencocokkan nilai. Misalnya, (\d)(\d) akan cocok dengan dua digit. /(\d)(\d)/ tidak akan cocok dengan dua digit.
• Kasus variabel kondisi perlu mencocokkan kasus variabel pengambilan. Misalnya, jika variabel kondisi saya adalah User-Agent, variabel pengambilan saya harus untuk User-Agent (yaitu {http_req_User-Agent_2}). Jika variabel kondisi saya didefinisikan sebagai agen pengguna, variabel pengambilan saya harus untuk agen pengguna (yaitu {http_req_user-agent_2}).
• Jika Anda ingin menggunakan seluruh nilai, Anda tidak boleh menyebutkan angka. Cukup gunakan format {http_req_headerName}, dll. tanpa groupNumber.

Variabel server

Gateway Aplikasi menggunakan variabel server untuk menyimpan informasi yang berguna tentang server, koneksi dengan klien, dan permintaan saat ini pada koneksi. Contoh informasi yang disimpan termasuk alamat IP klien dan jenis browser web. Variabel server berubah secara dinamis, misalnya, ketika halaman baru dimuat atau ketika formulir diposting. Anda dapat menggunakan variabel ini untuk mengevaluasi kondisi regenerasi dan meregenerasi header. Untuk menggunakan nilai variabel server untuk menulis ulang header, Anda perlu menentukan variabel ini dalam sintaks {var_serverVariableName}

Gateway aplikasi mendukung variabel server berikut:

Nama variabel	Deskripsi
tambahkan_x_diteruskan_untuk_proxy	Bidang header permintaan klien X-Forwarded-For dengan variabel client_ip (lihat penjelasan pada tabel ini) ditambahkan ke bidang dalam format IP1, IP2, IP3, dan sebagainya. Jika bidang X-Forwarded-For tidak ada di header permintaan klien, variabel add_x_forwarded_for_proxy sama dengan variabel $client_ip. Variabel ini berguna ketika Anda ingin menulis ulang header X-Forwarded-For yang diatur oleh Application Gateway sehingga header hanya berisi alamat IP tanpa informasi port.
sandi_yang_didukung	Daftar cipher yang didukung oleh klien.
sandian_digunakan	String ciphers digunakan untuk koneksi TLS yang telah dibuat.
ip_klien	Alamat IP klien tempat gateway aplikasi menerima permintaan. Jika ada proksi terbalik sebelum gateway aplikasi dan klien asal, client_ip mengembalikan alamat IP proksi terbalik.
client_port	Port klien.
client_tcp_rtt	Informasi tentang koneksi TCP klien. Tersedia pada sistem yang mendukung opsi soket TCP_INFO.
pengguna_klien	Ketika autentikasi HTTP digunakan, nama pengguna diberikan untuk autentikasi.
host	Dalam urutan prioritas ini: nama host dari baris permintaan, nama host dari bidang header permintaan Host, atau nama server yang cocok dengan permintaan. Contoh: Dalam permintaan http://contoso.com:8080/article.aspx?id=123&title=fabrikam, nilai host adalah contoso.com
cookie_name	Cookie nama.
http_method	Metode yang digunakan untuk membuat permintaan URL. Misalnya, GET atau POST.
http_status	Status sesi. Misalnya, 200, 400, atau 403.
Versi HTTP	Protokol permintaan. Biasanya HTTP/1.0, HTTP/1.1, atau HTTP/2.0.
query_string	Daftar pasangan variabel/nilai yang mengikuti ? dalam URL yang diminta. Contoh: Dalam permintaan http://contoso.com:8080/article.aspx?id=123&title=fabrikam, nilai query_string adalah id=123&title=fabrikam
byte_diterima	Panjang permintaan (termasuk baris permintaan, header, dan badan permintaan).
request_query	Argumen berada pada baris permintaan.
skema_permintaan	Skema permintaan: http atau https.
request_uri	Permintaan asli lengkap URI (dengan argumen). Contoh: dalam permintaan http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, nilai request_uri adalah /article.aspx?id=123&title=fabrikam
sent_bytes	Jumlah byte yang dikirim ke klien.
server_port	Port server yang menerima permintaan.
protokol koneksi SSL	Protokol koneksi TLS yang dibuat.
SSL diaktifkan	"Hidup" jika koneksi beroperasi dalam mode TLS. Jika tidak, berupa untai kosong.
uri_path	Mengidentifikasi sumber daya spesifik di host yang ingin diakses klien web. Variabel mengacu pada jalur URL asli sebelum manipulasi apa pun. Ini adalah bagian dari URI permintaan tanpa argumen. Misalnya, dalam permintaan http://contoso.com:8080/article.aspx?id=123&title=fabrikam, nilai uri_path adalah /article.aspx.

Variabel server autentikasi bersama

Application Gateway mendukung variabel server berikut untuk skenario autentikasi timbal balik. Gunakan variabel server ini seperti yang Anda lakukan pada variabel server lainnya.

Nama variabel	Deskripsi
sertifikat klien	Sertifikat klien dalam format PEM untuk koneksi SSL yang dibuat.
tanggal_akhir_sertifikat_klien	Tanggal selesai sertifikat klien.
sidik_jari_sertifikat_klien	Sidik jari SHA1 sertifikat klien untuk koneksi aman yang dibuat.
pengeluar_sertifikat_klien	Untai "DN pengeluar sertifikat" sertifikat klien untuk koneksi aman yang dibuat.
client_certificate_serial	Nomor seri sertifikat klien untuk koneksi aman yang dibuat.
tanggal_mulai_sertifikat_klien	Tanggal mulai sertifikat klien.
subjek_sertifikat_klien	Untai "DN subjek" sertifikat klien untuk koneksi aman yang dibuat.
verifikasi_sertifikat_klien	Hasil verifikasi sertifikat klien: SUCCESS, FAILED:<reason>, atau NONE jika sertifikat tidak ada.

Skenario umum untuk regenerasi header

Menghapus informasi port dari header X-Forwarded-For

Gateway Aplikasi menyisipkan header X-Forwarded-For ke semua permintaan sebelum meneruskan permintaan ke ujung belakang. Header ini berisi daftar port IP yang dipisahkan koma. Mungkin ada skenario di mana server backend hanya memerlukan header untuk berisi alamat IP. Anda bisa gunakan penulisan ulang header untuk menghapus informasi port dari header X-Forwarded-For. Salah satu cara untuk melakukan ini adalah dengan mengatur header ke variabel server add_x_forwarded_for_proxy. Atau, Anda juga dapat menggunakan variabel client_ip:

Menghapus IP Proxy dalam baris untuk digunakan dengan fitur sumber X-Forwarded-For dari firewall backend

Beberapa firewall pihak ketiga, juga disebut sebagai Network Virtual Appliances (NVAs), menentukan alamat IP sumber dengan menggunakan header masuk X-Forwarded-For alih-alih alamat IP sumber paket, yang sebaliknya akan mencerminkan alamat IP Application Gateway. Dalam banyak kasus, NVA hanya menampilkan alamat IP terbaru di header.

Ketika permintaan melintasi beberapa proksi (misalnya, Klien -> Azure Front Door -> Application Gateway -> NVA), alamat IP terbaru di X-Forwarded-For header dapat mewakili Azure Front Door daripada alamat IP klien asli. Untuk mempertahankan alamat IP klien, Anda dapat mengonfigurasi aturan penulisan ulang Application Gateway untuk mengatur X-Forwarded-For header ke http_req_X-Forwarded-For variabel server. Konfigurasi ini mencegah Application Gateway menambahkan alamat IP Azure Front Door atau proksi terbalik perantara lainnya, seperti yang ditunjukkan pada cuplikan layar berikut:

Ini menangkap header X-Forwarded-For masuk, yang akan menjadi alamat IP asli klien, dan meneruskannya seadanya daripada menambahkan AFD atau IP proksi ke header, memungkinkan NVA menunjukkan dan mengevaluasi IP klien asli.

Ubah URL pengalihan

Memodifikasi URL pengalihan dapat berguna dalam keadaan tertentu. Misalnya, Anda mungkin awalnya mengalihkan klien ke jalur seperti "/blog" tetapi sekarang ingin mengirimnya ke "/pembaruan" karena perubahan struktur konten.

Peringatan

Anda mungkin perlu mengubah URL pengalihan saat mengonfigurasi Application Gateway untuk menggantikan nama host ke backend. Dalam konfigurasi ini, backend melihat nama host yang berbeda dari browser. Pengalihan tidak menggunakan nama host yang benar. Konfigurasi ini tidak disarankan.

Untuk informasi selengkapnya tentang batasan dan implikasi konfigurasi tersebut, lihat Mempertahankan nama host HTTP asli antara proksi terbalik dan aplikasi web backend-nya. Untuk penyiapan yang direkomendasikan untuk App Service, lihat "Domain Kustom (disarankan)" di Mengonfigurasi App Service dengan Application Gateway. Menulis ulang header lokasi pada respons seperti yang dijelaskan dalam contoh berikut harus dianggap sebagai solusi dan tidak mengatasi akar penyebabnya.

Ketika app service mengirim respons pengalihan, layanan ini menggunakan nama host yang sama di header lokasi responsnya seperti yang ada di permintaan yang diterima dari gateway aplikasi. Jadi klien membuat permintaan langsung ke contoso.azurewebsites.net/path2 alih-alih melalui gateway aplikasi (contoso.com/path2). Tidak dianjurkan untuk melewati gateway aplikasi.

Anda dapat mengatasi masalah ini dengan mengatur nama host pada header lokasi menjadi nama domain dari gateway aplikasi.

Berikut adalah langkah-langkah untuk mengganti nama host:

1. Buat aturan penulisan ulang dengan kondisi yang memeriksa apakah header lokasi dalam respons berisi azurewebsites.net. Masukkan pola '(https?)://. azurewebsites.net(.).

2. Lakukan tindakan untuk menulis ulang header lokasi sehingga header memiliki nama host gateway aplikasi. Masukkan {http_resp_Location_1}://contoso.com{http_resp_Location_2} sebagai nilai header. Atau, Anda juga dapat menggunakan variabel server host untuk mengatur nama host agar sesuai dengan permintaan asli.

   

Implementasikan header HTTP keamanan untuk mencegah kerentanan

Anda dapat memperbaiki beberapa kerentanan keamanan dengan menerapkan header yang diperlukan dalam respons aplikasi. Header keamanan ini mencakup X-XSS-Protection, Strict-Transport-Security, dan Content-Security-Policy. Anda dapat menggunakan Gateway Aplikasi untuk mengatur header ini untuk semua respons.

Hapus header yang tidak diinginkan

Anda mungkin ingin menghapus header yang memperlihatkan informasi sensitif dari respons HTTP. Misalnya, Anda mungkin ingin menghapus informasi seperti nama server backend, sistem operasi, atau detail pustaka. Anda bisa menggunakan gateway aplikasi untuk menghapus header ini:

Anda tidak dapat membuat aturan penulisan ulang untuk menghapus header host. Jika Anda mencoba membuat aturan penulisan ulang dengan jenis tindakan yang diatur untuk menghapus dan header diatur ke host, itu menghasilkan kesalahan.

Periksa keberadaan header

Anda dapat mengevaluasi permintaan HTTP atau header respons untuk keberadaan variabel header atau server. Evaluasi ini hanya berguna ketika Anda ingin melakukan penulisan ulang header ketika terdapat header tertentu.

Skenario umum untuk regenerasi URL

Pemilihan jalur berbasis parameter

Untuk menyelesaikan skenario di mana Anda ingin memilih kumpulan backend berdasarkan nilai header, bagian dari URL, atau string kueri dalam permintaan, gunakan kombinasi kemampuan Penulisan Ulang URL dan perutean berbasis jalur.

Buat set penulisan ulang dengan kondisi yang memeriksa parameter tertentu (string kueri, header, dll.) lalu lakukan tindakan di mana ia mengubah jalur URL (pastikan Peta jalur Evaluasi ulang diaktifkan). Kaitkan set penulisan ulang ke aturan berbasis jalur. Aturan berbasis jalur harus berisi jalur URL yang sama yang ditentukan dalam set penulisan ulang dan kumpulan backend yang sesuai.

Dengan demikian, set penulisan ulang memungkinkan Anda memeriksa parameter tertentu dan menetapkannya jalur baru, dan aturan berbasis jalur memungkinkan Anda menetapkan kumpulan backend ke jalur tersebut. Selama "Tinjauan ulang peta jalur" diaktifkan, rute lalu lintas akan dievaluasi ulang berdasarkan jalur yang ditentukan dalam kelompok pengaturan ulang.

Untuk contoh kasus penggunaan menggunakan string kueri, lihat Merutekan lalu lintas menggunakan pemilihan jalur berbasis parameter di portal.

Meregenerasi parameter untai kueri berdasarkan URL

Pertimbangkan skenario situs web belanja di mana tautan yang terlihat pengguna sederhana dan dapat dibaca, tetapi server backend memerlukan parameter string kueri untuk menampilkan konten yang tepat.

Dalam hal ini, Application Gateway dapat mengambil parameter dari URL dan menambahkan pasangan kunci-nilai parameter tersebut ke dalam string kueri di URL. Misalnya, jika pengguna ingin menulis https://www.contoso.com/fashion/shirts ulang ke https://www.contoso.com/buy.aspx?category=fashion&product=shirts, Anda dapat mencapai tujuan ini melalui konfigurasi penulisan ulang URL berikut.

Kondisi - Jika variabel uri_path server sama dengan pola /(.+)/(.+)

Tindakan - Atur jalur URL ke buy.aspx dan untai kueri ke category={var_uri_path_1}&product={var_uri_path_2}

Untuk panduan langkah demi langkah guna mencapai skenario yang dijelaskan sebelumnya, lihat Menulis ulang URL dengan Application Gateway menggunakan portal Microsoft Azure.

Perangkap umum konfigurasi regenerasi

• Anda tidak dapat mengaktifkan 'Mengevaluasi ulang peta lintasan' untuk aturan perutean permintaan dasar. Pembatasan ini mencegah perulangan evaluasi tak terbatas untuk aturan perutean dasar.

• Untuk aturan perutean berbasis jalur, Anda memerlukan setidaknya satu aturan penulisan ulang kondisional atau satu aturan penulisan ulang tanpa mengaktifkan 'Evaluasi ulang peta jalur'. Persyaratan ini mencegah perulangan evaluasi tanpa henti untuk aturan perutean yang berbasis jalur.

• Jika perulangan dibuat secara dinamis berdasarkan input klien, permintaan masuk berakhir dengan kode kesalahan 500. Application Gateway terus melayani permintaan lain tanpa degradasi dalam skenario ini.

Menggunakan regenerasi URL atau regenerasi header Host dengan Web Application Firewall (WAF_v2 SKU)

Saat Anda mengonfigurasi penulisan ulang URL atau penulisan ulang header host, evaluasi WAF terjadi setelah modifikasi pada header permintaan atau parameter URL (pasca-penulisan ulang). Saat Anda menghapus penulisan ulang URL atau konfigurasi penulisan ulang header host di Application Gateway Anda, evaluasi WAF terjadi sebelum penulisan ulang header (pra-penulisan ulang). Urutan ini memastikan bahwa aturan WAF berlaku untuk permintaan terakhir yang diterima pool backend Anda.

Misalnya, Anda memiliki aturan penulisan ulang header berikut untuk header "Accept" : "text/html" - jika nilai header "Accept" sama dengan "text/html", maka tulis ulang nilai menjadi "image/png".

Dengan hanya pengaturan menulis ulang header, evaluasi WAF terjadi pada "Accept" : "text/html". Tetapi ketika Anda mengonfigurasi penulisan ulang URL atau penulisan ulang header host, evaluasi WAF terjadi pada "Accept" : "image/png".

Regenerasi URL vs Pengalihan URL

Untuk penulisan ulang URL, Application Gateway menulis ulang URL sebelum mengirim permintaan ke backend. Tindakan ini tidak mengubah apa yang dilihat pengguna di browser karena perubahan disembunyikan dari pengguna.

Untuk pengalihan URL, Application Gateway mengirimkan respons pengalihan ke klien dengan URL baru. Respons tersebut mengharuskan klien untuk mengirim ulang permintaannya ke URL baru yang disediakan dalam pengalihan. URL yang dilihat pengguna di browser diperbarui ke URL baru.

Batasan

• Penulisan ulang tidak didukung saat gateway aplikasi dikonfigurasi untuk mengalihkan permintaan atau menampilkan halaman kesalahan kustom.
• Nama header permintaan dapat berisi karakter alfanumerik dan tanda hubung. Nama header yang berisi karakter lain dibuang saat permintaan dikirim ke target backend.
• Nama header respons dapat berisi karakter alfanumerik dan simbol tertentu seperti yang didefinisikan dalam RFC 7230.
• Anda tidak dapat menulis ulang header X-Original-Host, Connection, dan upgrade.
• Penulisan ulang tidak didukung untuk respons 4xx dan 5xx yang dihasilkan langsung dari Application Gateway.

Langkah berikutnya

• Pelajari cara meregenerasi header HTTP dengan Application Gateway menggunakan portal Microsoft Azure
• Pelajari cara meregenerasi URL dengan Application Gateway menggunakan portal Microsoft Azure