Pada artikel sebelumnya kita telah membahas beberapa aspek utama Penulisan Ulang URL. Pada artikel terakhir seri ini, kita akan membahas beberapa detail dan karakteristik berbagai tingkat Penulisan Ulang URL.
Secara teoritis, Penulisan Ulang URL tingkat IIS yang ditulis dalam C atau C++ memiliki performa lebih tinggi daripada Penulisan Ulang URL tingkat ASP.NET yang ditulis dalam kode terkelola. Namun menurut saya perbedaan di area ini dapat diabaikan dalam banyak kasus, dan hampir tidak mungkin kinerja ini menjadi penghambat kinerja. Oleh karena itu, tingkat Penulisan Ulang URL yang dipilih umumnya tidak ditentukan oleh persyaratan kinerja aplikasi Anda. Jadi tingkat Penulisan Ulang URL manakah yang harus digunakan? Setelah menggunakan berbagai tingkat Penulisan Ulang URL, apa yang harus kita perhatikan? Saya di sini untuk berbicara tentang pandangan pribadi saya.
Meskipun komponen Penulisan Ulang URL saat ini dapat memenuhi sebagian besar aplikasi dalam hal fungsionalitas, pada titik tertentu, kita masih memerlukan beberapa fungsi khusus. Misalnya, Penulisan Ulang URL berdasarkan nama domain tidak mudah dicapai dengan komponen Penulisan Ulang URL saat ini. ISAPI Rewrite komersial saat ini dapat mendukung hal ini. Sayangnya, UrlRewriter.NET dan IIRF open source tidak memiliki fungsi yang memadai dalam hal ini. Semuanya dicocokkan berdasarkan jalur permintaan relatif terhadap situs, dan nama domain yang diminta tidak dapat digunakan sebagai kondisi pencocokan. Hal ini mengharuskan kita untuk memperluas komponen Penulisan Ulang URL. Bagi sebagian besar pengembang .NET, kode terkelola secara alami merupakan pilihan pertama untuk pengembangan. Saat ini, mungkin perlu memilih komponen penulisan ulang URL tingkat ASP.NET. Namun, banyak contoh ekstensi dapat ditemukan di Internet, baik itu UrlRewriter.NET di level ASP.NET atau IIRF di level IIS.
Namun nyatanya, jika kita ingin mencapai fungsi-fungsi di atas, kita juga bisa melakukannya dengan dua langkah. Pertama kita menggunakan IIRF untuk Penulisan Ulang URL di tingkat IIS, dan selanjutnya Penulisan Ulang URL di tingkat ASP.NET. Misalnya, jika sekarang kita ingin menulis ulang " http://jeffz.domain.com/articles " menjadi "/ArticleList.aspx?owner=jeffz", pertama-tama kita biarkan IIRF melakukan Penulisan Ulang URL pertama, dengan tujuan untuk menulis ulang " /articles" ditulis ulang menjadi "/ArticleList.aspx".
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
Dengan cara ini, mesin ASP.NET akan langsung menerima permintaan untuk /ArticleList.aspx. Kemudian di dalam ASP.NET, kita bisa melakukan Penulisan Ulang URL kedua (untuk kenyamanan, saya masih menulisnya di Global.asax, dan disarankan untuk menggunakan HttpModule tambahan di proyek).
dilindungi kekosongan Application_BeginRequest (pengirim objek , EventArgs e)
{
Konteks HttpContext = HttpContext .Saat ini;
string host = konteks.Permintaan.Url.Host;
pemilik string = host.Substring(0, host.IndexOf( '.' ));
konteks.RewritePath(context.Request.RawUrl + "?pemilik=" + pemilik);
}
Setelah dua kali Penulisan Ulang URL, efek yang kita inginkan telah tercapai (dalam proyek sebenarnya, kode di atas tidak dapat digunakan secara langsung karena perlu dinilai apakah ada Query String, dll.).
Selain itu, Penulisan Ulang URL tingkat ASP.NET hanya dapat berfungsi di ASP.NET (hal yang jelas). Jika Anda ingin Penulisan Ulang URL mendukung teknologi server lain seperti PHP, RoR, dll., Anda hanya dapat menggunakan Penulisan Ulang URL tingkat IIS. (atau fungsi Penulisan Ulang URL lainnya yang disediakan oleh teknologi server).
Beberapa karakter khusus tidak diperbolehkan muncul di URL, atau setelah muncul di URL, arti permintaannya berubah. Misalnya, kita perlu melakukan Penulisan Ulang URL pada halaman pencarian, menulis ulang "/Search/xxx" menjadi "/Search.aspx?xxx", lalu mendapatkan kata kunci yang diberikan oleh pengguna berdasarkan string setelah tanda tanya. Jika menggunakan UrlRewriter.NET, kita akan menggunakan konfigurasi berikut:
< rewriter >
< menulis ulang url = " ^/Pencarian/(.+)$ " ke = " ~/Search.aspx?$1 " memproses = " berhenti " />
</ rewriter >
Dalam keadaan normal, Penulisan Ulang URL ini berfungsi normal. Tetapi jika pengguna menggunakan "%" sebagai kata kunci, situasinya berbeda, karena kita akan menerima pesan halaman kesalahan berikut:
Ini karena "%" tidak diperbolehkan di URL. Anda dapat mengunjungi berbagai situs web dan mencoba meminta beberapa jalur seperti "ABC%25DEF" ("%25" diikuti oleh "%"), dan sebagian besar akan menemukan kesalahan "400 Permintaan Buruk". Namun, memasukkan "%" ke dalam Query String adalah sah - ya, bukankah kita menulis ulang kata kunci tersebut ke dalam Query String? Mengapa masih tidak berfungsi? Hal ini juga ditentukan oleh cara ASP.NET dijalankan.
Permintaan Buruk ditentukan pada langkah 3 gambar di atas, yaitu saat masih diinisialisasi. Penulisan Ulang URL kami hanya terjadi di acara BeginRequest di langkah 4. Jika permintaan berisi karakter ilegal, kami tidak mempunyai kesempatan untuk melakukan Penulisan Ulang URL sama sekali.
Jadi bagaimana kita mengatasi masalah ini? Dalam keadaan normal, tidak akan menjadi masalah besar jika kita menghapus % pada klien (beberapa situs melakukan hal ini), tetapi bagaimana jika kita harus menyimpannya? Kemudian gunakan Query String untuk meneruskan parameter, atau kita juga bisa menggunakan Penulisan Ulang URL level IIS. Masih mengambil IIRF sebagai contoh:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
Ketika permintaan dikirim ke IIS (langkah 1), dan setelah memilih ISAPI mana yang harus diserahkan selesai untuk eksekusi (Langkah 2) Penulisan Ulang URL terjadi sebelumnya. Setelah Penulisan Ulang URL, "%" di alamat telah ditransfer ke String Kueri, dan secara alami sah jika diserahkan ke ASP.NET untuk diproses.
Terakhir, mari kita bahas konfigurasi halaman kesalahan. Misalnya, secara umum kita akan mengonfigurasi halaman kesalahan 404 untuk aplikasi, sehingga ketika pengguna mengakses sumber daya yang tidak ada, kita dapat menampilkan halaman tertentu kepadanya, bukan prompt kesalahan default. Namun pada titik ini, tingkat Penulisan Ulang URL yang berbeda harus dikonfigurasi menggunakan metode yang berbeda.
Jika kita menggunakan Penulisan Ulang URL level ASP.NET, secara umum kita telah menyiapkan Pemetaan Wildcard di IIS, sehingga permintaan apa pun (termasuk html, jpg, dll.) akan diproses oleh ASP.NET. Jika sumber daya yang tidak ada diminta, kesalahan 404 akan dikeluarkan oleh ASP.NET, sehingga halaman kesalahan 404 harus dikonfigurasi di web.config:
< customErrors modus = " Aktif " defaultRedirect = " GenericErrorPage.htm " >
< kesalahan kode status = " 404 " redirect = " FileNotFound.htm " />
</ customErrors >
Jika kami menggunakan Penulisan Ulang Url level IIS, kami tidak akan mengonfigurasi Pemetaan Wildcard. Dengan kata lain, mesin ASP.NET hanya akan mulai bekerja ketika alamat setelah Rewrite adalah aspx (atau hal lain yang seharusnya ditangani oleh ASP.NET ISAPI). Jika pengguna meminta sumber daya yang tidak ada, kesalahan 404 akan dikeluarkan oleh IIS. Saat ini, halaman kesalahan 404 harus dikonfigurasi di IIS:
Sejauh ini topik Penulisan Ulang URL telah dibahas. Dalam perkembangan sebenarnya, Anda pasti akan menghadapi berbagai situasi yang berbeda, tetapi selama Anda memahami kunci metode Penulisan Ulang URL dan berpikir sesuai dengan cara program berjalan, saya yakin secara umum Anda tidak akan menemui masalah yang sulit.