Pertanyaan Redirect, Ubah URL atau Redirect HTTP ke HTTPS di Apache - Segala Sesuatu Yang Anda Inginkan Ketahui Tentang Mod_Rewrite Rules tetapi Takut untuk Tanya


Ini adalah sebuah Pertanyaan Kanonis tentang mod_rewrite Apache.

Mengubah URL permintaan atau mengarahkan pengguna ke URL yang berbeda dari yang awalnya mereka minta dilakukan menggunakan mod_rewrite. Ini termasuk hal-hal seperti:

  • Mengubah HTTP ke HTTPS (atau sebaliknya)
  • Mengubah permintaan ke halaman yang tidak lagi ada pengganti baru.
  • Memodifikasi format URL (seperti? Id = 3433 ke / id / 3433)
  • Menyajikan halaman yang berbeda berdasarkan browser, berdasarkan pengarah, berdasarkan apa pun yang mungkin di bawah bulan dan matahari.
  • Apa pun yang Anda ingin main-main dengan URL

Segala Sesuatu yang Anda Inginkan untuk Ketahui tentang Aturan Mod_Rewrite tetapi Takut Menanyakan!

Bagaimana saya bisa menjadi ahli dalam menulis aturan mod_rewrite?

  • Apa format dasar dan struktur aturan mod_rewrite?
  • Apa bentuk / rasa ekspresi reguler yang saya perlukan untuk memiliki pemahaman yang kuat?
  • Apa kesalahan / jebakan paling umum saat menulis aturan penulisan ulang?
  • Apa metode yang baik untuk menguji dan memverifikasi aturan mod_rewrite?
  • Apakah ada implikasi SEO atau kinerja dari aturan mod_rewrite yang harus saya ketahui?
  • Apakah ada situasi umum di mana mod_rewrite mungkin tampak seperti alat yang tepat untuk pekerjaan itu tetapi tidak?
  • Apa sajakah contoh umum?

Tempat untuk menguji aturan Anda

Itu htaccess tester situs web adalah tempat yang bagus untuk bermain-main dengan aturan Anda dan mengujinya. Ia bahkan menunjukkan output debug sehingga Anda dapat melihat apa yang cocok dan apa yang tidak.


257
2017-12-20 16:59




Gagasan di balik pertanyaan ini adalah memberikan jalan yang dekat untuk semua pertanyaan mod_rewrite tanpa akhir yang mendorong pengguna kami yang lebih biasa menjadi gila. Ini sangat mirip dengan apa yang dilakukan dengan subnetting di serverfault.com/questions/49765/how-does-subnetting-work . - Kyle Brandt♦
Juga, saya tidak benar-benar menginginkan terlalu banyak upvote dalam hal ini pertanyaan, tetapi mereka harus pergi ke jawabannya. Saya tidak ingin CW ini karena saya ingin memastikan poster mendapat kredit penuh untuk apa yang saya harapkan adalah mod_rewrite jawaban untuk mengakhiri semua pertanyaan mod_rewrite. - Kyle Brandt♦
Maaf, saya menjawab pertanyaan itu. ;-) Saya benar-benar berpikir itu perlu muncul di (atau dekat) bagian atas mod-rewrite pencarian tag / filter. - Steven Monday
Seseorang Lain (tm) harus menangani kasus penggunaan umum. Saya tidak cukup mengenal mereka untuk melakukan keadilan. - sysadmin1138♦
Mungkin pertanyaan ini harus dikaitkan dengan wiki tag mod-menulis ulang untuk membuat jalan bahkan lebih pendek. - beldaz


Jawaban:


urutan sintaks mod_rewrite

mod_rewrite memiliki beberapa aturan pemesanan spesifik yang memengaruhi pemrosesan. Sebelum ada yang dilakukan, RewriteEngine On direktif perlu diberikan karena ini mengaktifkan pemrosesan mod_rewrite. Ini harus sebelum arahan penulisan ulang lainnya.

RewriteCond mendahului RewriteRule membuat aturan ONE tunduk pada kondisional. Setiap RewriteRules berikut akan diproses seolah-olah mereka tidak tunduk pada conditional.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule $/blog/(.*)\.html        $/blog/$1.sf.html

Dalam kasus sederhana ini, jika perujuk HTTP berasal dari serverfault.com, redirect permintaan blog ke halaman serverfault khusus (kami khusus itu). Namun, jika blok di atas memiliki baris RewriteRule tambahan:

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule $/blog/(.*)\.html        $/blog/$1.sf.html
RewriteRule $/blog/(.*)\.jpg         $/blog/$1.sf.jpg

Semua file .jpg akan masuk ke halaman serverfault khusus, bukan hanya yang dengan perujuk menunjukkan itu berasal dari sini. Ini jelas bukan maksud dari bagaimana aturan-aturan ini ditulis. Itu bisa dilakukan dengan beberapa aturan RewriteCond:

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.html        /blog/$1.sf.html
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.jpg         /blog/$1.sf.jpg

Tetapi mungkin harus dilakukan dengan beberapa sintaks pengganti yang lebih rumit.

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

RewriteRule yang lebih kompleks berisi conditional untuk diproses. Tanda kurung terakhir, (html|jpg) memberi tahu RewriteRule agar cocok untuk keduanya html atau jpg, dan untuk mewakili string yang cocok sebagai $ 2 dalam string yang ditulis ulang. Ini secara logis identik dengan blok sebelumnya, dengan dua pasangan RewriteCond / RewriteRule, itu hanya melakukannya pada dua baris, bukan empat.

Beberapa baris RewriteCond secara implisit ANDed, dan dapat secara eksplisit ORed. Untuk menangani perujuk dari ServerFault dan Pengguna Super (eksplisit ATAU):

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)    [OR]
RewriteCond %{HTTP_REFERER}                ^https?://superuser\.com(/|$)
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

Untuk melayani halaman yang dirujuk ServerFault dengan browser Chrome (implisit AND):

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)
RewriteCond %{HTTP_USER_AGENT}             ^Mozilla.*Chrome.*$
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

RewriteBase juga urutan khusus karena menentukan bagaimana mengikuti RewriteRule arahan menangani pemrosesan mereka. Ini sangat berguna dalam file .htaccess. Jika digunakan, itu harus menjadi petunjuk pertama di bawah "RewriteEngine on" dalam file .htaccess. Ambil contoh ini:

RewriteEngine On
RewriteBase /blog
RewriteCond %{HTTP_REFERER}           ^https?://serverfault\.com(/|$)
RewriteRule ^(.*)\.(html|jpg)         $1.sf.$2

Ini memberitahu mod_rewrite bahwa URL khusus yang saat ini ditangani telah tiba dengan cara http://example.com/blog/ bukannya jalur direktori fisik (/ home / $ Username / public_html / blog) dan memperlakukannya sesuai. Karena ini, itu RewriteRule menganggap itu string-mulai menjadi setelah "/ blog" di URL. Inilah hal yang sama yang ditulis dengan dua cara berbeda. Satu dengan RewriteBase, yang lain tanpa:

RewriteEngine On

##Example 1: No RewriteBase##
RewriteCond %{HTTP_REFERER}                                   ^https?://serverfault\.com(/|$)
RewriteRule /home/assdr/public_html/blog/(.*)\.(html|jpg)     $1.sf.$2

##Example 2: With RewriteBase##
RewriteBase /blog
RewriteCond %{HTTP_REFERER}           ^https?://serverfault\.com(/|$)
RewriteRule ^(.*)\.(html|jpg)         $1.sf.$2

Seperti yang terlihat, RewriteBase memungkinkan penulisan ulang aturan untuk memanfaatkan web-situs path ke konten daripada web-server, yang dapat membuatnya lebih dimengerti oleh mereka yang mengedit file seperti itu. Juga, mereka dapat membuat arahan lebih pendek, yang memiliki daya tarik estetika.


Sintaks pencocokan RewriteRule

RewriteRule sendiri memiliki sintaks kompleks untuk string yang cocok. Saya akan membahas bendera (hal-hal seperti [PT]) di bagian lain. Karena Sysadmin belajar dengan contoh lebih sering daripada dengan membaca halaman manual Saya akan memberikan contoh dan menjelaskan apa yang mereka lakukan.

RewriteRule ^/blog/(.*)$    /newblog/$1

Itu .* membangun cocok dengan satu karakter tunggal (.) nol atau lebih kali (*). Menyertakannya dalam tanda kurung memberi tahu untuk memberikan string yang dicocokkan sebagai variabel $ 1.

RewriteRule ^/blog/.*/(.*)$  /newblog/$1

Dalam hal ini, yang pertama. * TIDAK diapit oleh orang tua sehingga tidak diberikan ke string yang ditulis ulang. Aturan ini menghapus tingkat direktori di situs blog baru. (/blog/2009/sample.html menjadi /newblog/sample.html).

RewriteRule ^/blog/(2008|2009)/(.*)$   /newblog/$2

Dalam hal ini, ekspresi kurung pertama membentuk grup yang cocok. Ini menjadi $ 1, yang tidak diperlukan dan karena itu tidak digunakan dalam string yang ditulis ulang.

RewriteRule ^/blog/(2008|2009)/(.*)$   /newblog/$1/$2

Dalam hal ini, kami menggunakan $ 1 dalam string yang ditulis ulang.

RewriteRule ^/blog/(20[0-9][0-9])/(.*)$   /newblog/$1/$2

Aturan ini menggunakan sintaks bracket khusus yang menentukan karakter jarak. [0-9] cocok dengan angka 0 hingga 9. Aturan khusus ini akan menangani tahun dari 2000 hingga 2099.

RewriteRule ^/blog/(20[0-9]{2})/(.*)$  /newblog/$1/$2

Ini melakukan hal yang sama dengan aturan sebelumnya, tetapi bagian {2} memberitahukannya untuk mencocokkan karakter sebelumnya (ekspresi bracket dalam kasus ini) dua kali.

RewriteRule ^/blog/([0-9]{4})/([a-z]*)\.html   /newblog/$1/$2.shtml

Kasus ini akan cocok dengan huruf kecil apa pun dalam ekspresi pencocokan kedua, dan melakukannya untuk sebanyak mungkin karakter. Itu \. membangun mengatakan untuk memperlakukan periode sebagai periode yang sebenarnya, bukan karakter khusus dalam contoh sebelumnya. Akan rusak jika nama file memiliki tanda hubung di dalamnya.

RewriteRule ^/blog/([0-9]{4})/([-a-z]*)\.html  /newblog/$1/$2.shtml

Perangkap nama file ini dengan tanda hubung di dalamnya. Namun, seperti - adalah karakter khusus dalam ekspresi braket, itu harus menjadi pertama karakter dalam ekspresi.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-zA-Z]*)\.html   /newblog/$1/$2.shtml

Versi ini menjebak nama file apa pun dengan huruf, angka atau - karakter dalam nama file. Ini adalah bagaimana Anda menentukan beberapa set karakter dalam ekspresi braket.


Bendera RewriteRule

Bendera pada aturan penulisan ulang memiliki sejumlah makna dan penggunaan khusus.

RewriteRule ^/blog/([0-9]{4})/([-a-z]*).\html  /newblog/$1/$2.shtml  [L]

Bendera adalah [L] di akhir ekspresi di atas. Beberapa bendera dapat digunakan, dipisahkan oleh koma. Dokumentasi terkait menggambarkan masing-masing, tetapi di sini mereka tetap:

L = Terakhir. Hentikan pemrosesan RewriteRules setelah yang satu ini cocok. Jumlah pesanan!
C = Rantai. Lanjutkan memproses RewriteRule berikutnya. Jika aturan ini tidak cocok, maka aturan berikutnya tidak akan dieksekusi. Lebih lanjut tentang ini nanti.
E = Tentukan variabel lingkungan. Apache memiliki berbagai variabel lingkungan yang dapat memengaruhi perilaku server web.
F = Dilarang. Mengembalikan kesalahan 403-Forbidden jika aturan ini cocok.
G = Hilang. Mengembalikan kesalahan 410-Hilang jika aturan ini cocok.
H = Handler. Memaksa permintaan untuk ditangani seolah-olah itu adalah tipe MIME yang ditentukan.
N = Selanjutnya. Memaksa aturan untuk memulai kembali dan mencocokkan kembali. HATI-HATI! Loops dapat terjadi.
NC = Tidak ada kasus. Memungkinkan jpg untuk mencocokkan jpg dan JPG.
NE = Tidak ada jalan keluar. Mencegah penulisan ulang karakter khusus (.? # & Dll) ke dalam ekivalen kode hex mereka.
NS = Tidak ada subrequest. Jika Anda menggunakan sisi-server-termasuk, ini akan mencegah pertandingan ke file yang disertakan.
P = Proksi. Memaksa aturan untuk ditangani oleh mod_proxy. Secara transparan menyediakan konten dari server lain, karena server web Anda menjemputnya dan menyajikannya kembali. Ini adalah bendera berbahaya, karena yang ditulis dengan buruk akan mengubah web-server Anda menjadi proxy terbuka dan Itu Buruk.
PT = Lewat. Memperhitungkan pernyataan Alias ​​dalam pencocokan RewriteRule.
QSA = QSAppend. Saat string asli berisi kueri (http://example.com/thing?asp=foo) menambahkan string kueri asli ke string yang ditulis ulang. Biasanya itu akan dibuang. Penting untuk konten dinamis.
R = Redirect. Berikan pengalihan HTTP ke URL yang ditentukan. Juga dapat memberikan kode pengalihan yang tepat [R = 303]. Sangat mirip dengan RedirectMatch, yang lebih cepat dan harus digunakan bila memungkinkan.
S = Lewati. Lewati aturan ini.
T = Ketik. Tentukan jenis mime dari konten yang dikembalikan. Sangat mirip dengan AddType direktif.

Anda tahu bagaimana saya mengatakan itu RewriteCond berlaku untuk satu dan hanya satu aturan? Nah, Anda bisa mendapatkannya dengan berantai.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.html        /blog/$1.sf.html     [C]
RewriteRule ^/blog/(.*)\.jpg         /blog/$1.sf.jpg

Karena RewriteRule pertama memiliki bendera Rantai, maka aturan penulisan ulang kedua akan dijalankan ketika yang pertama melakukannya, yaitu ketika aturan RewriteCond yang sebelumnya dicocokkan. Berguna jika ekspresi reguler Apache membuat otak Anda sakit. Namun, metode all-in-one-line yang saya tunjuk di bagian pertama lebih cepat dari sudut pandang pengoptimalan.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-zA-Z]*)\.html   /newblog/$1/$2.shtml

Ini dapat dibuat lebih sederhana melalui bendera:

RewriteRule ^/blog/([0-9]{4})/([-0-9a-z]*)\.html   /newblog/$1/$2.shtml   [NC]

Juga, beberapa bendera juga berlaku untuk RewriteCond. Khususnya, NoCase.

RewriteCond %{HTTP_REFERER}        ^https?://serverfault\.com(/|$)     [NC]

Akan cocok dengan "ServerFault.com"


219
2017-12-20 17:44



Sudah selesai dilakukan dengan baik. [pengisi] - EEAA
Sangat bagus mod_rewrite dan primer regex. +1. - Steven Monday
Terkadang berguna untuk mengetahui bahwa RewriteCond sebenarnya diproses setelah itu RewriteRule dicocokkan. Anda mungkin ingin mengatakan "lebih lanjut tentang itu nanti" di dekat bagian atas di mana Anda mengatakan "RewriteCond mendahului RewriteRule membuat aturan ONE tunduk pada conditional." Anda mungkin ingin menyebutkan bahwa regexes adalah ekspresi reguler yang kompatibel dengan Perl. Juga Anda memiliki tanda kutip ekstra di "... RewriteRule menganggap itu string-start ..." - Dennis Williamson
RewriteRule ^/blog/.*/(.*)$ /newblog/$1 tidak cocok dengan pertama komponen direktori - penulisan ulang secara serakah. /.*/(.*) cocok dengan kedua / 1 / (2) / dan / 1/2/3/4/5 / (6) /, jadi Anda perlu / [^ /] * / hanya mencocokkan jalur FIRST komponen. - adaptr
@ sysadmin1138, saya pikir jawaban ini bagus tetapi akan lebih baik jika Anda menguraikan lebih lanjut pada bendera E, N, NS, P, PT, dan S dengan contoh karena bendera-bendera itu tidak jelas bagaimana cara kerjanya, dll. - Pacerier


Apa format dasar dan   struktur aturan mod_rewrite?

Saya akan menunda jawaban bagus sysadmin1138 tentang hal-hal ini.

Apa bentuk / rasa regulernya   Saya harus memiliki ekspresi yang solid   pegang dari?

Selain urutan sintaks, pencocokan sintaksis / ekspresi reguler, dan tanda-tanda RewriteRule yang digariskan oleh sysadmin1138, saya percaya itu menyebutkan bahwa mod_rewrite mengekspos variabel lingkungan Apache berdasarkan header permintaan HTTP dan konfigurasi Apache.

saya ingin merekomendasikan Tutorial Debug mod_rewrite AskApache untuk daftar variabel lengkap yang mungkin tersedia untuk mod_rewrite.

Apa yang paling umum   kesalahan / jebakan saat menulis penulisan ulang   aturan?

Sebagian besar masalah dengan RewriteRule berasal dari kesalahpahaman sintaks / kegagalan PCRE untuk melepaskan karakter khusus secara tepat atau kurangnya wawasan tentang isi variabel yang digunakan untuk pencocokan.

Masalah umum dan pemecahan masalah yang disarankan:

  • 500 Internal Server Error - Hapus kontrol kereta Windows dalam file konfigurasi (s) jika ada, pastikan mod_rewrite diaktifkan (bungkus arahan di IfModule bersyarat untuk menghindari skenario ini), periksa sintaks direktif, beri komentar arahan sampai masalah teridentifikasi
  • Pengalihan loop - Manfaatkan RewriteLog dan RewriteLogLevel, beri komentar arahan sampai masalah teridentifikasi

Apa metode yang baik untuk menguji dan   memverifikasi aturan mod_rewrite?

Pertama, lihat isi variabel lingkungan yang Anda rencanakan cocok - jika Anda menginstal PHP, ini semudah menambahkan blok berikut ke aplikasi Anda:

<?php
  var_dump($_SERVER);
?>

... kemudian tuliskan aturan Anda (sebaiknya untuk menguji pada server pengembangan) dan catat setiap pencocokan atau aktivitas yang tidak konsisten di Apache Anda Catatan eror mengajukan.

Untuk aturan yang lebih kompleks, gunakan mod_rewrite RewriteLog direktif untuk mencatat aktivitas ke suatu file dan mengaturnya RewriteLogLevel 3

Apakah ada SEO atau kinerja   implikasi dari aturan mod_rewrite I   harus sadar?

AllowOverride all dampak kinerja server sebagai Apache harus diperiksa .htaccess file dan mengurai arahan dengan setiap permintaan - jika mungkin, simpan semua arahan dalam konfigurasi VirtualHost untuk situs Anda atau aktifkan .htaccess menimpa hanya untuk direktori yang membutuhkannya.

Milik Google Pedoman Webmaster secara eksplisit menyatakan: "Jangan menipu pengguna Anda atau menyajikan konten yang berbeda ke mesin pencari daripada yang Anda tampilkan kepada pengguna, yang sering disebut sebagai 'cloaking.'" - hindari membuat arahan mod_rewrite yang menyaring robot mesin pencari.

Robot mesin telusur lebih menyukai konten 1: 1: pemetaan URI (ini adalah dasar untuk memeringkatkan tautan ke konten) - jika Anda menggunakan mod_rewrite untuk membuat pengalihan sementara atau Anda melayani konten yang sama di bawah beberapa URI, pertimbangkan menetapkan URI kanonis dalam dokumen HTML Anda.

Apakah ada situasi umum di mana   mod_rewrite mungkin tampak seperti benar   alat untuk pekerjaan tetapi tidak?

Ini adalah topik besar (dan berpotensi diperdebatkan) dalam haknya sendiri - lebih baik (IMHO) untuk membahas penggunaan berdasarkan kasus per kasus dan membiarkan penanya menentukan apakah resolusi yang disarankan sesuai dengan kebutuhan mereka.

Apa sajakah contoh umum?

Trik dan Tips mod_rewrite AskApache mencakup hampir setiap kasus penggunaan umum yang muncul secara teratur, namun, solusi "benar" untuk pengguna tertentu dapat bergantung pada kecanggihan konfigurasi pengguna dan arahan yang ada (yang mengapa umumnya merupakan ide yang baik untuk melihat lain arahan yang dimiliki pengguna setiap kali muncul pertanyaan mod_rewrite).


38
2017-12-21 01:00



Terima kasih atas tautan AskApache. Itu yang saya cari! - sica07
The AskApache badut secara resmi tidak didukung oleh ASF. Banyak dari apa yang dia katakan masih bisa diperdebatkan atau salah. - adaptr
@adaptr Tolong bagikan sumber daya superior yang sepertinya Anda sadari. - danlefree
"situasi umum di mana mod_rewrite mungkin tampak seperti alat yang tepat untuk pekerjaan itu tetapi tidak?" - sederhana redirect, di mana mod_rewrite belum digunakan. Gunakan mod_alias Redirect atau RedirectMatch sebagai gantinya. Lihat juga dokumen Apache: Kapan tidak menggunakan mod_rewrite - MrWhite


Seperti banyak admin / pengembang saya telah melawan seluk-beluk aturan penulisan ulang selama bertahun-tahun dan saya tidak puas dengan dokumentasi Apache yang ada, jadi saya memutuskan sebagai proyek pribadi untuk sampai ke dasar bagaimana mod_rewrite benar-benar bekerja dan berinteraksi dengan sisa inti Apache, jadi selama beberapa bulan terakhir saya telah memberikan contoh uji strace + mengebor kode sumber untuk menangani semua ini.

Berikut adalah beberapa komentar utama yang perlu ditulis ulang oleh pengembang aturan:

  • Beberapa aspek penulisan ulang adalah umum untuk konfigurasi server, virtual host, direktori, .htaccess processing namun
  • Beberapa pemrosesan sangat berbeda untuk konfigurasi root (konfigurasi server, host virtual dan direktori) sebagai lawan dari PerDir (.htaccess) pengolahan.
  • Lebih buruk lagi karena proses PerDir hampir dapat secara sembarangan memicu siklus INTERNAL REDIRECT, elemen konfigurasi akar harus ditulis sadar bahwa pemrosesan PerDir seperti itu dapat memicu hal ini.

Saya akan pergi sebagai fas untuk mengatakan bahwa karena ini Anda hampir perlu membagi komunitas pengguna yang ditulis ulang menjadi dua kategori dan memperlakukan mereka sebagai sepenuhnya terpisah:

  • Mereka yang memiliki akses root ke konfigurasi Apache. Ini biasanya admin / pengembang dengan aplikasi dedicated server / VM, dan pesan di sini cukup sederhana: hindari menggunakan .htaccess file jika memungkinkan; lakukan segalanya di server Anda atau konfigurasi host. Debugging cukup mudah karena pengembang dapat mengatur debugging dan memiliki akses ke file rewrite.log.

  • Pengguna layanan yang dihosting bersama (SHS).

    • Pengguna semacam itu memiliki menggunakan .htaccess / Perdir memproses karena tidak ada alternatif yang tersedia.
    • Lebih buruk lagi, tingkat keterampilan pengguna tersebut (sejauh menggunakan regexp driven ladder-logic of mod_rewrite) umumnya jauh lebih sedikit daripada admin berpengalaman.
    • Apache dan penyedia hosting tidak menawarkan bantuan debugging / diagnostik. Satu-satunya informasi diagnostik adalah pengalihan yang sukses, pengalihan ke URI yang salah. atau kode status 404/500. Ini membuat mereka bingung dan tidak berdaya.
    • Apache sangat lemah menjelaskan cara penulisan ulang untuk kasus penggunaan ini. Misalnya tidak memberikan penjelasan yang jelas tentang apa itu PerDir .htaccessfile dipilih dan mengapa. Itu tidak menjelaskan seluk-beluk bersepeda PerDir dan bagaimana menghindari hal ini.

Mungkin ada komunitas ketiga: admin dan staf pendukung di penyedia SHS yang berakhir dengan satu kaki di kedua kamp dan harus menanggung akibat di atas.

Saya telah menulis beberapa posting blog bergaya artikel (mis Lebih lanjut tentang menggunakan aturan Menulis ulang dalam file .htaccess) yang mencakup banyak poin mendetail yang tidak akan saya ulangi di sini untuk menjaga agar posting ini tetap singkat. Saya memiliki layanan bersama sendiri serta mendukung beberapa proyek khusus & VM FLOSS. Saya mulai menggunakan LAMP VM standar sebagai kendaraan uji untuk akun SHS saya, tetapi pada akhirnya saya merasa lebih baik untuk melakukan mirror VM yang tepat (dijelaskan sini).

Namun, dalam hal bagaimana komunitas admin harus mendukung .htaccess pengguna, saya merasa bahwa kita perlu mengembangkan dan menawarkan:

  • Deskripsi yang koheren tentang bagaimana sistem penulisan ulang benar-benar berfungsi dalam pemrosesan PerDir
  • Seperangkat pedoman / praktik terbaik tentang cara menulis .htaccess menulis ulang aturan
  • Sebuah parser penulisan ulang berbasis web sederhana semacam mirip dengan parser html W3C, tetapi di mana pengguna dapat memasukkan URI tes atau menguji vektor yang sama dan mendapatkan log langsung dari alur logika penulisan ulang /
  • Petunjuk tentang cara mendapatkan diagnostik bawaan dari aturan Anda (mis.

    • Menggunakan [E=VAR:EXPR] mengeksploitasi fakta itu EXPR akan memperluas backreferences ($ N atau% N) untuk menjadikannya tersedia sebagai diagnostik untuk skrip target.
    • Jika Anda memesan aturan penulisan ulang Anda menggunakan flag [OR], [C], [SKIP] dan [L] sehingga seluruh skema penulisan ulang berfungsi tanpa kebutuhan untuk mengeksploitasi redirection internal, maka Anda dapat menambahkan yang berikut sebagai aturan 1 untuk menghindari semua kerumitan perulangan:

      RewriteCond %{ENV:REDIRECT_STATUS} !=""
      RewriteRule .  -  [L]
      

21
2018-01-14 16:50



Ini terdokumentasi dengan baik. Mengapa Anda mengatakan dokumentasi tidak menjelaskan ini? - adaptr
Yang harus Anda lakukan adalah berlangganan ke .htaccess topik dan Anda akan melihat. Kebanyakan pemula merasa bingung - sebagian besar dari ini memiliki pengalaman pertama mereka dari layanan LAMP dan mod_rewrite pada layanan bersama dan oleh karena itu tidak memiliki akses root ke konfigurasi sistem / vhost dan harus menggunakan pemrosesan per dir melalui .htaccessfile. Ada perbedaan penting yang harus dimulainya "pemula". Saya akan menganggap diri saya sebagai pengguna-kekuatan dan masih menemukan seluk-beluk. Seperti yang saya katakan, saya harus menggunakan strace dan pemindaian kode sumber untuk menyelesaikan beberapa aspek. Saya tidak membutuhkannya. :-( - TerryE
Saya sangat setuju. "Kami perlu membagi komunitas pengguna yang ditulis ulang menjadi dua kategori dan memperlakukan mereka sebagai terpisah sepenuhnya." Beberapa pengguna menggunakan shared hosting dan perlu mengandalkan .htaccess, yang sangat rapuh, rumit, dan membingungkan, bahkan bagi para ahli. Saya masih kesulitan. - Ryan


Menggunakan rewritemap

Ada banyak hal yang dapat Anda lakukan dengan rewritemaps. Rewritemaps dideklarasikan menggunakan direktif Rewritemap, dan kemudian dapat digunakan baik dalam evaluasi RewritCond, dan dalam Subsitutions RewriteRule.

Sintaks umum untuk RewriteMap adalah:

RewriteMap MapName MapType:MapSource

Sebagai contoh:

RewriteMap examplemap txt:/path/to/file/map.txt

Anda kemudian dapat menggunakan nama map untuk konstruksi seperti ini:

${examplemap:key}

Peta berisi pasangan kunci / nilai. Jika kunci ditemukan, nilainya di subsituted. Peta sederhana hanyalah file teks biasa, tetapi Anda dapat menggunakan peta hash, dan bahkan query SQL. Detail lebih lanjut ada di dokumen:

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap

Unescaping string.

Ada empat peta internal yang dapat Anda gunakan untuk melakukan manipulasi. Terutama string unescaping dapat berguna.

Sebagai contoh: Saya ingin menguji string "café" di string kueri. Namun, peramban akan melarikan diri dari ini sebelum mengirimnya ke server saya, jadi saya harus mencari tahu versi URL yang luput adalah untuk setiap string yang ingin saya tandingkan, atau saya hanya dapat membukanya ...

RewriteMap unescape int:unescape

RewriteCond %{QUERY_STRING}  (location|place)=(.*)
RewriteCond ${unescape:%2}   café
RewriteRule ^/find/$         /find/1234? [L,R]

Perhatikan bagaimana saya menggunakan satu RewriteCond untuk hanya menangkap argumen yang menekuk parameter string kueri, dan kemudian gunakan peta di penulisan ulang keduaBaca untuk menghapusnya. Ini kemudian dibandingkan. Perhatikan juga bagaimana saya perlu kepada kami% 2 sebagai kunci dalam rewritemap, karena% 1 akan berisi "lokasi" atau "tempat". Ketika Anda menggunakan tanda kurung untuk pola kelompok, mereka juga akan ditangkap, apakah Anda berencana untuk menggunakan hasil tangkapan atau tidak ...


15
2018-04-06 11:57



Kalimat terakhir tidak sepenuhnya benar. Itu mod_rewrite mesin regexp mendukung grup yang tidak menangkap seperti (?:location|place) dan ini hanya akan memiliki satu pengambilan dalam contoh. - TerryE


Apa yang paling umum   kesalahan / jebakan saat menulis penulisan ulang   aturan?

Perangkap yang sangat mudah adalah ketika Anda menulis ulang URL yang mengubah jalur yang terlihat, mis. dari /base/1234/index.html untuk /base/script.php?id=1234. Setiap gambar atau CSS dengan jalur relatif ke lokasi skrip tidak akan ditemukan oleh klien. Sejumlah opsi untuk menyelesaikan ini dapat ditemukan di faq ini.


12
2018-01-01 04:02



Terima kasih atas tautannya. Khususnya ketika bekerja dengan anggota tim lain yang tidak akrab dengan menulis ulang, saya menemukan menambahkan a <base> tag menjadi yang paling mudah diikuti dan masih memungkinkan jalur relatif. - kontur