Beranda>Tutorial Pemrograman Jaringan>Tutorial ASP.NET

Penulisan Ulang URL(2): Menggunakan komponen untuk Penulisan Ulang URL

Penulis：Eve Cole Waktu Pembaruan：2009-06-29 23:46:44
Prinsip komponen Penulisan Ulang URL tingkat asp.net sangat sederhana, sebenarnya hanya mendengarkan acara BeginRequest dan menentukan URL target sesuai dengan konfigurasi. Dalam proyek yang pernah saya ikuti sebelumnya, saya menemukan bahwa frekuensi penggunaan URLRewriter sebagai komponen Penulisan Ulang URL sangat tinggi. Saya rasa ini mungkin karena ini disediakan oleh Microsoft.
Jika Anda ingin menggunakan URLRewriter, langkah alami pertama adalah mengkonfigurasi HttpModule di web.config:

<httpModul>
< tambahkan
nama = " Penulis Modul "
ketik = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpModul>

Maka saatnya untuk melakukan konfigurasi (Catatan: Sangat disarankan untuk menggunakan atribut configPath untuk mengekstrak konfigurasi ke file tambahan untuk memudahkan pengelolaan):
<configBagian>
< bagian
nama = " Konfigurasi Penulis Ulang "
ketik = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configBagian>
<RewriterConfig>

<Aturan>

<Aturan Penulis Ulang>

< Cari > ~/tag/([w]+)/ </ Cari >

< Kirim Ke > ~/Tags.aspx?Tag=$1 </ Kirim Ke >

</Aturan Penulis Ulang>

</ Aturan >
</RewriterConfig>

Ekspresi reguler adalah hal yang luar biasa, dapat dicocokkan dan ditangkap. Dalam contoh di atas, kita memindahkan "/tag/xxx" yang memenuhi kondisi LookFor ke halaman Tags.aspx, dan menggunakan xxx sebagai nilai item Tag QueryString, sehingga kita bisa meneruskan HttpContext.Request.QueryString dalam kode .["Tag"] untuk mendapatkan nilainya.
Fungsionalitas URLRewriter cukup untuk sebagian besar aplikasi, tetapi saya selalu tidak menyukainya. Tetapi jika Anda harus bertanya kepada saya mengapa saya tidak menyukainya, saya tidak dapat memberi tahu Anda tentang Yinmao yang jelek itu. Mungkin hanya masalah pada metode konfigurasi ini. Saat menggunakan URL Rewriter, bagian konfigurasi seringkali sangat panjang. Setiap item konfigurasi memerlukan total 4 baris kode dari <RewriterRule> hingga </RewriterRule>. “Ini terlalu XML”, pikir saya, kenapa tidak menggunakan Atribut XML? Ini mengurangi setiap item konfigurasi menjadi 1 baris - tapi itu adalah penyimpangan.
Jadi jika saat ini saya ingin melakukan URL Rewrite, saya sering menggunakan komponen open source UrlRewriter.NET yang diproduksi oleh Intelligencia . Meskipun nama ini sangat mirip dengan nama sebelumnya, namun fungsinya jauh lebih unggul dari nama sebelumnya. Komponen ini relatif mirip dengan URLRewriter yang digunakan (pada kenyataannya, tampaknya semua komponen Penulisan Ulang URL serupa).

<configBagian>
< bagian
nama = " penulis ulang "

 ketik = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,

Intelligencia.UrlRewriter " />
</configBagian>


<penulis ulang>

< menulis ulang
url = " ^/Pengguna/(d+)$ "
ke = " ~/Pengguna.aspx?id=$1 "
memproses = " berhenti " />

< menulis ulang
url = " ^/Pengguna/(w+)$ "
ke = " ~/Pengguna.aspx?nama=$1 "
memproses = " berhenti " />
</penulis ulang>


< sistem.web >

<httpModul>

< tambahkan
nama = " Penulis Ulang Url "

 ketik = " Intelligencia.UrlRewriter.RewriterHttpModule,

Intelligencia.UrlRewriter " />

</httpModul>
< /sistem.web >
Mari kita lihat item konfigurasi <rewriter /> dari aturan penulisan ulang. Berbeda dari URLRewriter, UrlRewriter.NET menggunakan metode favorit saya yaitu satu node per aturan, yang membuat aturan penulisan ulang seluruh proyek menjadi lebih sederhana. Tapi apa yang dimaksud dengan pemrosesan = "berhenti"? Ini tentang cara UrlRewriter.NET menangani aturan penulisan ulang. Ketika UrlRewriter.NET menemukan aturan penulisan ulang yang cocok, ia tidak akan berhenti di sini, tetapi akan terus mencari kecocokan lainnya. Aturan penulisan ulang terakhir yang cocok dengan permintaan saat ini pada akhirnya akan berlaku. Jika kita memerlukan UrlRewriter.NET untuk diterapkan setelah menemukan kecocokan, kita perlu menyetel atribut pemrosesan ke berhenti. Misalnya, dalam konfigurasi di atas, jika "/Pengguna/" diikuti dengan angka, ID pengguna akan digunakan untuk pencarian, jika tidak, nama pengguna yang diberikan saat ini akan dipertimbangkan.
Jika UrlRewriter.NET lebih sederhana dalam konfigurasinya, ia tidak memiliki keunggulan dibandingkan URLRewriter. Namun kemampuan UrlRewriter.NET jauh lebih dari itu. Apa yang baru saja kami gunakan sebenarnya hanyalah salah satu Action yang disediakannya.

  • jika
  • kecuali
  • penulisan ulang
  • pengalihan
  • setstatus
  • dilarang
  • hilang
  • tidak diizinkan
  • tidak ditemukan
  • tidak diterapkan
  • addheader
  • setcookie
  • setproperty
Tindakan saja tidak cukup. UrlRewriter.NET juga menyediakan Kondisi, Transformasi, Dokumen Default, Parser, Penangan Kesalahan, Logger, dan fungsi lainnya, dan dapat lolos. Ekspresi untuk "mewakili" logika yang kompleks. Ini bukan konfigurasi, ini hanyalah pemrograman! Benar sekali, UrlRewriter.NET dapat digunakan untuk mengekspresikan beberapa logika permintaan-balasan melalui konfigurasi, yang tidak diragukan lagi memberi kita kemudahan yang luar biasa. Tidak mungkin saya menjelaskan seluruh aspek UrlRewriter.NET secara detail di sini. Teman-teman yang berminat bisa melihat lebih dekat dari Referensi yang disediakan oleh situs resminya. “Jika Anda memiliki komponen seperti ini, apa lagi yang Anda minta?” Namun, saya tetap ingin merekomendasikan komponen lain di sini. Karena dalam beberapa kasus khusus, UrlRewriter.NET tidak dapat memenuhi persyaratan kami. eh? Tidak bisakah ia berkembang dengan sendirinya? Itu benar, tapi - mari kita selesaikan dulu, dan saya akan menjelaskan masalah ini di artikel terakhir seri ini. UrlRewriter.NET menyediakan URL Rewriter di tingkat ASP.NET. Jika Anda ingin melakukan Penulisan Ulang URL di tingkat IIS, Anda harus menggunakan metode lain. ISAPI Rewrite adalah komponen yang terkenal untuk Penulisan Ulang URL di level IIS Sayangnya, ini adalah komponen komersial dan mengharuskan kita membelinya dengan dolar AS. Oleh karena itu saya merekomendasikan produk open source lain di sini: IIRF (Ionic's Isapi Rewrite Filter) .
Karena Penulisan Ulang URL dilakukan di tingkat IIS, metode konfigurasi IIRF berbeda dari UrlRewriter.NET. Jika Anda ingin menggunakan IIRF, Anda perlu menambahkan IsapiRewrite4.dll ke daftar Filter ISAPI di Situs Web:
IIRF dikonfigurasi melalui file ini. IsapiRewrite4.ini dan IsapiRewrite4.dll dapat ditempatkan di direktori yang sama:
Aturan Penulisan Ulang ^/User/(d+)$ /User.aspx?id=$1 [I, L]
Aturan Penulisan Ulang ^/Pengguna/(w+)$ /Pengguna.aspx?nama=$1 [I, L]
Aturan penulisan ulang IIRF adalah "RewriteRule <url-pattern> <destination> [<modifiers>]". Tidak ada batasan jumlah spasi antar setiap bagian, tetapi harus berupa spasi, bukan karakter spasi lain seperti Tab . Tak perlu dikatakan, "pola url" dan "tujuan", kuncinya terletak pada pengubah. Ada banyak modifier untuk IIRF. Disini saya hanya akan memperkenalkan dua modifier yang digunakan di atas. "I" berarti pencocokan tidak tergantung huruf besar/kecil. Fungsi "L" mirip dengan pemrosesan = "berhenti" di UrlRewriter.NET. Ini akan langsung berlaku ketika kecocokan ditemukan dan tidak akan melanjutkan pencarian.
Meskipun IIRF merupakan komponen open source, fungsinya masih relatif kuat. Terutama setelah menggabungkan RewriteCond (Kondisi Penulisan Ulang), aturan penulisan ulang yang lebih kompleks dapat diterapkan. Misalnya, konfigurasi berikut menulis ulang permintaan direktori akar yang berisi kata Googlebot di UserAgent ke sumber daya tertentu:
Penulisan UlangCond %{HTTP_USER_AGENT} ^Googlebot.*
Aturan Penulisan Ulang ^/ $/Googlebot.html [L]
Terakhir, mari kita lihat perbedaan antara kedua komponen Rewrite. Jelas sekali, perbedaan terbesar adalah bahwa keduanya ditulis ulang pada level yang berbeda. Kedua diagram skema di bawah ini menjelaskan bagaimana dalam dua kasus tersebut mereka mengubah "/User/jeffz" yang seharusnya memperoleh hasil "404 Resource Not Found". "/Pengguna/nama=jeffz".
Yang pertama adalah Penulisan Ulang URL oleh UrlRewriter.NET di level ASP.NET:
Berikutnya adalah Penulisan Ulang URL IIRF pada level IIS:

Dengan dua komponen ini, saya yakin kita tidak memerlukan hal lain lagi untuk mengimplementasikan URL Rewrite.