Regenerasi header HTTP dan URL dengan Application Gateway
Application Gateway memungkinkan Anda meregenerasi konten permintaan dan respons yang dipilih. Dengan fitur ini, Anda dapat menerjemahkan URL, parameter string kueri, dan mengubah header permintaan dan respons. Fitur ini juga memungkinkan Anda untuk menambahkan kondisi untuk memastikan bahwa URL atau header akan dapat diregenerasi ketika 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 untuk meneruskan informasi tambahan dengan permintaan atau respons. Dengan menulis ulang header ini, Anda dapat menyelesaikan tugas-tugas penting, seperti menambahkan bidang header terkait keamanan seperti HSTS/ X-XSS-Protection, menghapus bidang header respons yang mungkin mengungkapkan informasi sensitif, dan menghapus informasi port dari header X-Forwarded-For.
Anda dapat menulis ulang semua header dalam permintaan dan respons, kecuali untuk Connectionheader , dan Upgrade . Anda juga dapat menggunakan gateway aplikasi untuk membuat header kustom dan menambahkannya ke permintaan dan respons yang dirutekan melaluinya. Untuk mempelajari cara meregenerasi header permintaan dan respons dengan Application Gateway menggunakan portal Microsoft Azure, lihat di sini.
Jalur URL dan untai kueri
Dengan kemampuan regenerasi URL di Application Gateway, Anda dapat:
Meregenerasi nama host, jalur dan untai kueri dari 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 meregenerasi URL dengan Application Gateway menggunakan portal Microsoft Azure, lihat di sini.
Memahami Penulisan Ulang di Application Gateway
Set penulisan ulang adalah kumpulan Aturan Perutean, Kondisi, dan Tindakan.
Meminta asosiasi aturan perutean: Konfigurasi penulisan ulang dikaitkan dengan pendengar sumber melalui aturan peruteannya. Saat Anda menggunakan aturan perutean jenis Dasar, konfigurasi penulisan ulang dikaitkan dengan pendengarnya dan berfungsi sebagai penulisan ulang global. Saat Anda menggunakan aturan perutean berbasis Jalur, konfigurasi penulisan ulang didefinisikan sesuai 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: Ini adalah konfigurasi opsional. Berdasarkan kondisi yang Anda tentukan, Application Gateway akan mengevaluasi konten permintaan dan respons HTTP.S. "Tindakan penulisan ulang" berikutnya akan 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 DAN logis. 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:
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. Ketahui lebih lanjut 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}. Anda dapat menggunakan{capt_header_value_matcher}saat nilai diambil dari header respons "Set-Cookie" Set Tindakan. Ketahui selengkapnya tentang pengambilan di bawah Kumpulan tindakan. - Variabel server - Untuk menggunakan variabel server, tentukan sintaks sebagai
{var_serverVariable}. Daftar variabel Server yang didukung.
Saat 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 disimpan tanpa dicentang, jalur URL asli akan digunakan untuk mencocokkan pola jalur di peta jalur URL. Jika diatur ke true, peta jalur URL akan dievaluasi kembali untuk memeriksa kecocokan dengan jalur yang diregenerasi. Mengaktifkan tombol ini membantu dalam merutekan permintaan ke regenerasi pos kumpulan ujung belakang.
Pencocokan dan pencocokan pola
Pencocokan patten dan pengambilan didukung di bawah Kondisi dan Tindakan (di bawah Tindakan, hanya didukung untuk header tertentu).
Pencocokan pola
Application Gateway menggunakan ekspresi reguler untuk pencocokan pola. Anda harus menggunakan ekspresi yang kompatibel dengan Ekspresi Reguler 2 (RE2) saat menulis sintaks pencocokan pola Anda.
Anda dapat menggunakan pencocokan pola di bawah Kondisi dan Tindakan.
- Kondisi: Ini digunakan 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 properti "HeaderValueMatcher". Jika diambil, nilainya dapat digunakan sebagai {capt_header_value_matcher}. Karena mungkin ada beberapa Set-Cookie, pola yang cocok di sini memungkinkan Anda untuk mencari cookie tertentu. Contoh: Untuk versi agen pengguna tertentu, Anda ingin menulis 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 - Jenis penulisan ulang: Header respons, Jenis tindakan: Set, Nama header: Set-Cookie, Pencocok 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 Seperangkat Aturan Inti 3.1 atau yang lebih lama, Anda mungkin mengalami masalah saat menggunakan Ekspresi Reguler yang Kompatibel Perl (PCRE) saat melakukan pernyataan lookahead dan lookbehind (negatif atau positif).
Sintaks untuk menangkap
Pola juga dapat digunakan untuk mengambil sub-string 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 suka; Perl hanya terus mendefinisikan lebih banyak variabel bernomor bagi Anda untuk mewakili untai yang ditangkap tersebut. 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 nomornya. 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 |
|---|---|
| add_x_forwarded_for_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. |
| ciphers_supported | Daftar cipher yang didukung oleh klien. |
| ciphers_used | 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. |
| client_user | Ketika autentikasi HTTP digunakan, nama pengguna diberikan untuk autentikasi. |
| tuan rumah | 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. |
| http_version | Protokol permintaan. Biasanya HTTP/1.0, HTTP/1.1, atau HTTP/2.0. |
| query_string | Daftar pasangan variabel/nilai yang mengikuti tanda "?" pada URL yang diminta. Contoh: Dalam permintaan http://contoso.com:8080/article.aspx?id=123&title=fabrikam, nilai query_string adalah id=123&title=fabrikam |
| received_bytes | Panjang permintaan (termasuk baris permintaan, header, dan badan permintaan). |
| request_query | Argumen berada pada baris permintaan. |
| request_scheme | 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. |
| ssl_connection_protocol | Protokol koneksi TLS yang dibuat. |
| ssl_enabled | "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 dengan cara yang sama seperti di atas dengan variabel server lainnya.
| Nama variabel | Deskripsi |
|---|---|
| client_certificate | Sertifikat klien dalam format PEM untuk koneksi SSL yang dibuat. |
| client_certificate_end_date | Tanggal selesai sertifikat klien. |
| client_certificate_fingerprint | Sidik jari SHA1 sertifikat klien untuk koneksi aman yang dibuat. |
| client_certificate_issuer | Untai "DN pengeluar sertifikat" sertifikat klien untuk koneksi aman yang dibuat. |
| client_certificate_serial | Nomor seri sertifikat klien untuk koneksi aman yang dibuat. |
| client_certificate_start_date | Tanggal mulai sertifikat klien. |
| client_certificate_subject | Untai "DN subjek" sertifikat klien untuk koneksi aman yang dibuat. |
| client_certificate_verification | 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:
Ubah URL pengalihan
Modifikasi URL pengalihan dapat berguna dalam keadaan tertentu. Misalnya: klien awalnya dialihkan ke jalur seperti "/blog" tetapi sekarang harus dikirim ke "/update" karena perubahan struktur konten.
Peringatan
Kebutuhan untuk memodifikasi URL pengalihan terkadang muncul dalam konteks konfigurasi di mana Application Gateway dikonfigurasi untuk mengambil alih nama host terhadap backend. Nama host seperti yang terlihat oleh backend dalam hal ini berbeda dari nama host seperti yang dilihat oleh browser. Dalam situasi ini, pengalihan tidak akan menggunakan nama host yang benar. Konfigurasi ini tidak disarankan.
Batasan dan implikasi konfigurasi tersebut dijelaskan dalam Mempertahankan nama host HTTP asli antara proksi terbalik dan aplikasi web backend-nya. Penyiapan yang direkomendasikan untuk App Service adalah mengikuti instruksi untuk "Domain Kustom (disarankan)" di Mengonfigurasi App Service dengan Application Gateway. Menulis ulang header lokasi pada respons seperti yang dijelaskan dalam contoh di bawah ini harus dianggap sebagai solusi sementara 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:
Buat aturan penulisan ulang dengan kondisi yang mengevaluasi apakah header lokasi dalam respons berisi azurewebsites.net. Masukkan pola
(https?):\/\/.*azurewebsites\.net(.*)$.Lakukan tindakan untuk menulis ulang header lokasi sehingga header memiliki nama host gateway aplikasi. Lakukan dengan memasukkan
{http_resp_Location_1}://contoso.com{http_resp_Location_2}sebagai nilai header. Atau, Anda juga dapat menggunakan variabel serverhostuntuk 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:
Tidak dimungkinkan untuk 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, Anda dapat menggunakan kombinasi kemampuan Penulisan Ulang URL dan perutean berbasis jalur.
Untuk melakukan ini, 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). Set penulisan ulang kemudian harus dikaitkan dengan 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 pengguna untuk memeriksa parameter tertentu dan menetapkannya jalur baru, dan aturan berbasis jalur memungkinkan pengguna untuk menetapkan kumpulan backend ke jalur tersebut. Selama "Peta jalur evaluasi ulang" diaktifkan, perutean lalu lintas berdasarkan jalur yang ditentukan dalam set penulisan 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 harus sederhana dan mudah terbaca, tetapi server ujung belakang memerlukan parameter untai kueri untuk menampilkan konten yang tepat.
Dalam hal ini, Application Gateway dapat menangkap parameter dari URL dan menambahkan pasangan kunci-nilai untai kueri dari parameter yang berasal dari URL. Misalnya, pengguna ingin meregenerasi, https://www.contoso.com/fashion/shirts ke https://www.contoso.com/buy.aspx?category=fashion&product=shirts, dapat dicapai melalui konfigurasi regenerasi URL berikut.
Kondisi - Jika variabel server uri_path 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 untuk mencapai skenario yang dijelaskan di atas, lihat Meregenerasi URL dengan Application Gateway menggunakan portal Microsoft Azure
Perangkap umum konfigurasi regenerasi
Mengaktifkan 'Evaluasi ulang peta jalur' tidak diizinkan untuk aturan perutean permintaan dasar. Ini untuk mencegah perulangan evaluasi tak terbatas untuk aturan perutean dasar.
Perlu ada setidaknya 1 aturan penulisan ulang kondisional atau 1 aturan penulisan ulang yang tidak memiliki 'Peta jalur reevaluasi' diaktifkan untuk aturan perutean berbasis jalur untuk mencegah perulangan evaluasi tak terbatas untuk aturan perutean berbasis jalur.
Permintaan masuk akan diakhiri dengan kode galat 500 jika perulangan dibuat secara dinamis berdasarkan input klien. Application Gateway terus melayani permintaan lain tanpa degradasi dalam skenario seperti itu.
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). Dan saat Anda menghapus penulisan ulang URL atau konfigurasi penulisan ulang header host di Application Gateway Anda, evaluasi WAF dilakukan sebelum penulisan ulang header (pra-penulisan ulang). Perintah ini memastikan bahwa aturan WAF diterapkan pada permintaan akhir yang akan diterima oleh kumpulan ujung belakang.
Misalnya, Anda memiliki aturan regenerasi header berikut untuk header "Accept" : "text/html" - jika nilai header "Accept" sama dengan "text/html", regenerasi nilai ke "image/png".
Di sini, dengan hanya penulisan ulang header yang dikonfigurasi, evaluasi WAF dilakukan pada "Accept" : "text/html". Tetapi ketika Anda mengonfigurasi penulisan ulang URL atau penulisan ulang header host, maka evaluasi WAF dilakukan pada "Accept" : "image/png".
Regenerasi URL vs Pengalihan URL
Untuk penulisan ulang URL, Application Gateway menulis ulang URL sebelum permintaan dikirim ke backend. Ini tidak akan 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. Sebagai gantinya, hal tersebut mengharuskan klien untuk mengirim ulang permintaannya ke URL baru yang disediakan di 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 akan dibuang saat permintaan dikirim ke target backend.
- Nama header respons dapat berisi karakter alfanumerik dan simbol tertentu seperti yang didefinisikan dalam RFC 7230.
- Header koneksi dan peningkatan tidak dapat diregenerasi
- Penulisan ulang tidak didukung untuk respons 4xx dan 5xx yang dihasilkan langsung dari Application Gateway