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 untai kueri, serta 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.

Catatan

Fitur regenerasi header HTTP dan URL hanya tersedia untuk Application Gateway v2 SKU

Jenis regenerasi yang didukung

Header permintaan dan respons

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.

Application Gateway memungkinkan Anda menambahkan, menghapus, atau memperbarui header permintaan dan respons HTTP saat paket permintaan dan respons berpindah antara kumpulan klien dan backend.

Untuk mempelajari cara meregenerasi header permintaan dan respons dengan Application Gateway menggunakan portal Microsoft Azure, lihat di sini.

Header yang didukung

Anda bisa meregenerasi semua header di permintaan dan respons, kecuali untuk header Koneksi dan Peningkatan. Anda juga dapat menggunakan gateway aplikasi untuk membuat header kustom dan menambahkan ke permintaan dan respons yang sedang dirutekan melaluinya.

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 meregenerasi URL dari semua permintaan pada seorang 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.

Tindakan menulis ulang

Anda menggunakan tindakan regenerasi untuk menentukan URL, header permintaan, atau header respons yang ingin Anda regenerasi dan nilai baru tempat Anda ingin melakukan regenerasi. Nilai URL atau header baru atau yang sudah ada dapat diatur ke jenis nilai berikut:

• Teks
• Header permintaan. Untuk menentukan header permintaan, Anda perlu menggunakan sintaks {http_req_headerName}
• Header respons. Untuk menentukan header respons, Anda perlu menggunakan sintaks {http_resp_headerName}
• Variabel server. Untuk menentukan variabel server, anda perlu menggunakan sintaks {var_serverVariable}. Lihat daftar variabel server yang didukung
• Kombinasi teks, header permintaan, header respons, dan variabel server.

Kondisi Regenerasi

Anda dapat menggunakan kondisi regenerasi, konfigurasi opsional, untuk mengevaluasi konten permintaan dan respons HTTP dan melakukan regenerasi hanya ketika satu atau beberapa kondisi terpenuhi. Gateway aplikasi menggunakan jenis variabel berikut untuk mengevaluasi konten permintaan dan respons:

• Header HTTP dalam permintaan
• Header HTTP dalam respons
• Variabel server Application Gateway

Anda dapat menggunakan kondisi untuk mengevaluasi apakah variabel tertentu ada, apakah variabel yang ditentukan cocok dengan nilai tertentu, atau dengan pola tertentu.

Pencocokan Pola

Application Gateway menggunakan regex untuk pencocokan pola dalam kondisi. Anda harus menggunakan ekspresi yang kompatibel dengan Ekspresi Reguler 2 (RE2) saat menulis kondisi Anda. 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).

Menangkap

Untuk menangkap subuntai untuk digunakan nanti, letakkan tanda kurung di sekitar subpola yang cocok dengannya dalam definisi regex kondisi. 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. Beberapa contoh dari ref:

• (\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

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.

Setelah ditangkap, Anda dapat mereferensikannya dalam set 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}
• Untuk variabel server, Anda harus menggunakan {var_serverVariableName_groupNumber}. Misalnya, {var_uri_path_1} atau {var_uri_path_2}

Catatan

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 meregenerasi header, Anda harus 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 sangat berguna ketika Anda ingin menulis ulang header X-Forwarded-For yang ditetapkan oleh Gateway Aplikasi 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 akan 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. Ini adalah bagian dari URI permintaan tanpa argumen. Contoh: 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.

Konfigurasi Penulisan Ulang

Untuk mengonfigurasi aturan regenerasi, Anda perlu membuat seperangkat aturan regenerasi dan menambahkan konfigurasi aturan regenerasi di dalamnya.

Seperangkat aturan regenerasi berisi:

• Meminta asosiasi aturan perutean: Konfigurasi regenerasi dikaitkan dengan pendengar sumber melalui aturan perutean. Ketika Anda menggunakan aturan perutean dasar, konfigurasi regenerasi dihubungkan dengan pendengar sumber dan merupakan regenerasi header global. Ketika Anda menggunakan aturan perutean berbasis jalur, konfigurasi regenerasi ditentukan pada peta jalur URL. Dalam hal ini, aturan hanya berlaku untuk area jalur tertentu dari sebuah situs. Anda dapat membuat beberapa set regenerasi dan menerapkan tiap set regenerasi ke beberapa pendengar. Tetapi Anda hanya dapat menerapkan satu set penulisan ulang ke listener tertentu.

• Kondisi Regenerasi: Konfigurasi ini bersifat opsional. Kondisi Penulisan Ulang mengevaluasi konten permintaan dan respons dari HTTP. Tindakan penulisan ulang akan terjadi jika permintaan atau respons dari HTTP cocok dengan kondisi tulis ulang. 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 logis.

• Jenis regenerasi: Ada 3 jenis regenerasi yang tersedia:

  • Meregenerasi header permintaan
  • Meregenerasi header respons
  • Menulis ulang komponen URL
    • Jalur URL: Nilai tempat jalur akan diregenerasi.
    • String Kueri URL: Nilai tempat string kueri akan diregenerasi.
    • Mengevaluasi ulang peta jalur: Digunakan untuk menentukan apakah peta jalur URL akan dievaluasi ulang atau tidak. 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 ulang untuk memeriksa kecocokan dengan jalur yang ditulis ulang. Mengaktifkan tombol ini membantu dalam merutekan permintaan ke regenerasi pos kumpulan ujung belakang.

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 'Evaluasi ulang peta jalur' yang 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 akan 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 regenerasi URL atau regenerasi header host, evaluasi WAF akan terjadi setelah modifikasi pada parameter header permintaan atau URL (pascaregenerasi). Dan saat Anda menghapus konfigurasi regenerasi URL atau regenerasi header host di Application Gateway, evaluasi WAF akan dilakukan sebelum regenerasi header (praregenerasi). 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 regenerasi header yang dikonfigurasi, evaluasi WAF akan dilakukan pada "Accept" : "text/html". Tetapi ketika Anda mengonfigurasi regenerasi URL atau regenerasi header host, maka evaluasi WAF akan dilakukan pada "Accept" : "image/png".

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. Sehingga klien akan membuat permintaan langsung ke contoso.azurewebsites.net/path2 dan bukan 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 mengevaluasi 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. Lakukan dengan memasukkan {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:

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 ujung belakang berdasarkan nilai header, bagian dari URL, atau untai kueri dalam permintaan, Anda dapat menggunakan kombinasi kemampuan Regenerasi URL dan perutean berbasis jalur. Misalnya, jika Anda memiliki situs web belanja dan kategori produk dilewatkan sebagai untai kueri di URL, dan Anda ingin merutekan permintaan tersebut ke ujung belakang berdasarkan untai kueri, maka:

Langkah 1: Buat peta jalur seperti yang ditunjukkan pada gambar di bawah ini

Langkah 2 (a): Buat set regenerasi yang memiliki 3 aturan regenerasi:

• Aturan pertama memiliki kondisi yang memeriksa variabel query_string untuk category=shoes dan memiliki tindakan yang meregenerasi jalur URL ke /listing1 dan mengaktifkanEvaluasi kembali peta jalur

• Aturan kedua memiliki kondisi yang memeriksa variabel query_string untuk category=bags dan memiliki tindakan yang meregenerasi jalur URL ke /listing2 dan mengaktifkanEvaluasi kembali peta jalur

• Aturan ketiga memiliki kondisi yang memeriksa variabel query_string untuk category=accessories dan memiliki tindakan yang meregenerasi jalur URL ke /listing3 dan mengaktifkanEvaluasi kembali peta jalur

Langkah 2 (b): Hubungkan set regenerasi ini dengan jalur default dari aturan berbasis jalur di atas

Sekarang, jika pengguna meminta contoso.com/listing?category=any, maka akan dicocokkan dengan jalur default karena tidak ada pola jalur di peta jalur (/listing1, /listing2, /listing3) yang akan cocok. Karena Anda menghubungkan set regenerasi di atas dengan jalur ini, set regenerasi ini akan dievaluasi. Karena string kueri tidak akan cocok dengan kondisi dalam salah satu dari 3 aturan penulisan ulang dalam set penulisan ulang ini, tidak ada tindakan penulisan ulang yang akan terjadi dan oleh karena itu, permintaan akan dirutekan tidak berubah ke backend yang terkait dengan jalur default (yaitu GenericList).

Jika pengguna meminta contoso.com/listing?category=shoes, maka jalur default akan dicocokkan lagi. Namun, dalam hal ini kondisi dalam aturan pertama akan cocok dan oleh karena itu, tindakan yang terkait dengan kondisi akan dijalankan yang akan menulis ulang jalur URL ke /listing1 dan mengevaluasi ulang peta jalur. Ketika peta jalur dievaluasi ulang, permintaan sekarang akan cocok dengan jalur yang terkait dengan pola /listing1 dan permintaan akan dirutekan ke backend yang terkait dengan pola ini, yaitu ShoesListBackendPool.

Catatan

Skenario ini dapat diperluas ke setiap nilai header atau cookie, jalur URL, untai kueri atau variabel server berdasarkan kondisi yang ditentukan dan pada dasarnya memungkinkan Anda untuk merutekan permintaan berdasarkan kondisi tersebut.

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

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 akan diperbarui ke URL baru.

Batasan

• Jika respons memiliki lebih dari satu header dengan nama yang sama, maka menulis ulang nilai salah satu header tersebut akan menghilangkan header lain pada respons. Hal ini biasanya dapat terjadi dengan header Set-Cookie karena Anda dapat memiliki lebih dari satu header Set-Cookie dalam sebuah respons. Salah satu skenario tersebut adalah ketika Anda menggunakan layanan aplikasi dengan gateway aplikasi dan telah mengonfigurasi afinitas sesi berbasis cookie di gateway aplikasi. Dalam hal ini respons akan berisi dua header Set-Cookie: satu digunakan oleh app service, misalnya: Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net dan satu lagi untuk afinitas gateway aplikasi, misalnya, Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. Menulis ulang salah satu header Set-Cookie dalam skenario ini dapat menghapus header Set-Cookie lainnya dari respons.
• 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

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