REQUEST_URI tidak cocok dengan jalur dan nama file eksplisit

May 30 2019

Benar-benar bingung, karena bentuk dan sintaksnya tampak bagus.

RewriteCond untuk REQUEST_URI tidak cocok dengan jalur eksplisit dan nama file. Saat diisolasi, RewriteCond untuk REQUEST_FILENAME cocok dengan baik. Saya telah memverifikasi menggunakan phpinfo () bahwa REQUEST_URI berisi garis miring di depan, dan telah menguji tanpa garis miring, juga.

Tujuannya di sini adalah untuk mengetahui bahwa permintaan untuk file ini dan, jika tidak ada, maka lemparkan 410.

RewriteCond %{REQUEST_URI} ^/dir1/dir2/dir3/v_9991_0726dd5b5e8dd67a214c0c243436d131_all\.css$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ - [R=410,L]

Saya tidak ingin menghilangkan Cond pertama, karena saya hanya ingin melakukan ini untuk beberapa file yang mirip dengan ini.

PEMBARUAN I

mencoba mendapatkan tes definitif. Uji persiapan:

  • testmee.txt tidak ada
  • permintaan untuk testmee.txt di root
  • memverifikasi bahwa request_uri cocok, dengan mengarahkan ke google
  • tidak bisa mendapatkan 410 saat hanya menggunakan Cond pertama
  • (saat hanya menggunakan Cond pertama, server melayani 404, bukan 410)
  • (menggunakan kedua Conds, server melayani 404, bukan 410)
  • BISA mendapatkan 410 saat hanya menggunakan Cond kedua
RewriteCond %{REQUEST_URI} ^/testmee\.txt$ #RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ - [R=410,L]

melawan

#RewriteCond %{REQUEST_URI} ^/testmee\.txt$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ - [R=410,L]

PEMBARUAN II

Tanggapan untuk MrWhite:

ughh, gejala yang sama. Mungkin harus hidup dengan googlebot mencapai 404 daripada 410 yang diinginkan untuk css / js yang sudah ketinggalan zaman. Mungkin tidak ada masalah dalam jangka panjang.

Terima kasih atas pengalihan uji request_uri itu. Semuanya bekerja normal dalam tes tersebut. Nama halaman, dll. Dikembalikan seperti yang diharapkan, di URL var = rewrite.

Pada titik ini, saya pikir itu pasti ada penanganan internal 404 yang terkait dengan ekstensi jenis file. Lihat petunjuk di bawah. Saya memiliki perangkat lunak keranjang belanja PrestaShop, dan itu harus memaksa 404 pada jenis file.

Ini akan mengarahkan ke google (untuk menegaskan kecocokan pola):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^testmee\.txt$ http://www.google.com/ [L]
(L flag is needed or else other Rules further down will interfere.)

Ini akan terus menghasilkan 404, bukan 410:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^testmee\.txt$ - [NC,R=410]

Dan sebagai uji kontrol, ini akan menghasilkan 410:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ - [NC,R=410]

Jika jenis file adalah css pada pengujian gagal di atas, maka pengontrol 404 kustom saya tidak dipanggil. Saya baru saja mendapatkan Respons 404 biasa, tanpa 404 kustom yang dibungkus dengan semua template situs saya.

Sebagai contoh:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^testmee\.css$ - [NC,R=410]

Saya khawatir saya telah menyia-nyiakan sebagian waktu Anda. Permintaan maaf saya. Saya tidak pernah membayangkan bahwa kode PrestaShop akan memaksa 404 berdasarkan jenis file, tetapi saya tidak dapat melihat penjelasan lain. Saya bisa menggali lebih dalam dan mungkin menemukan tempat di Pengendali yang melakukannya. Tapi harus istirahat.

Jawaban

1 MrWhite May 31 2019 at 01:04

Ini sebenarnya bukan jawaban yang solid, lebih dari sekadar hal untuk mencoba membantu men-debug ini dan membatalkan beberapa mitos ...

Saya telah memverifikasi menggunakan phpinfo()yang REQUEST_URIberisi garis miring di depan

Ya, REQUEST_URIvariabel server Apache memang mengandung garis miring di depan. Ini berisi jalur URL lengkap.

Namun, REQUEST_URIvariabel server Apache belum tentu sama dengan $_SERVER['REQUEST_URI']superglobal PHP - pada kenyataannya, variabel tersebut tidak benar-benar sama sama sekali. Ada beberapa perbedaan signifikan antara variabel-variabel ini (dalam beberapa hal mungkin agak disayangkan mereka memiliki nama yang sama). Khususnya, superglobal PHP berisi URL awal dari permintaan dan menyertakan string kueri (jika ada) dan tidak% -decoded. Sedangkan variabel server Apache dengan nama yang sama berisi URL yang ditulis ulang (tidak harus URL yang diminta) dan tidak mengandung string kueri dan% -decoded.

Jadi, itulah mengapa saya bertanya apakah Anda memiliki direktif mod_rewrite lainnya. Anda bisa saja mengalami konflik. Jika direktif lain menulis ulang URL, maka kondisinya tidak akan pernah cocok (meskipun superglobal PHP menyarankan bahwa itu harus).

Tampaknya jika saya meletakkan ini di bagian atas, bendera Terakhir akan berhenti diproses untuk perjalanan itu, mengembalikan 410

Arahan ini tentunya harus berada di bagian atas .htaccessfile, untuk menghindari URL ditulis ulang sebelumnya. The Lbendera ini sebenarnya berlebihan bila digunakan dengan R=410(apa-apa selain 3xx) - itu tersirat dalam kasus ini.

Lalu saya ubah hasilnya menjadi "lempar 410" dan hasilnya 404.

Hal itu pasti dapat disebabkan oleh penggantian sisi server. Tapi Anda bisa melempar 410 dalam situasi lain, jadi itu sepertinya mengesampingkan itu. Namun, Anda dapat mengatur ulang dokumen kesalahan .htaccessjika ragu (kecuali jika Anda sudah menggunakan dokumen kesalahan kustom):

ErrorDocument 410 default
RewriteCond %{REQUEST_URI} ^/dir1/dir2/dir3/v_9991_0726dd5b5e8dd67a214c0c243436d131_all\.css$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ - [R=410,L]

Meskipun ini tidak benar-benar membuat perbedaan pada bagaimana aturan berperilaku, Anda tidak memerlukan RewriteCondarahan pertama yang memeriksa REQUEST_URI. Anda harus melakukan pemeriksaan ini pada RewriteRule pola (yang akan lebih efisien, karena ini diproses terlebih dahulu). Sebagai contoh:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^dir1/dir2/dir3/v_9991_0726dd5b5e8dd67a214c0c243436d131_all\.css$ - [NC,R=410]

The NCflag harus berlebihan.

Namun, konflik dengan arahan yang ada adalah penyebab yang paling mungkin. Hapus semua arahan lainnya. Apakah Anda masih melihat perilaku yang sama?


Anda dapat menguji nilai REQUEST_URIvariabel server. Anda dapat mengeluarkan pengalihan dan meneruskan REQUEST_URIsebagai parameter URL, atau menetapkan variabel lingkungan (tetapi Anda perlu memperhatikan REDIRECT_<var>setiap penulisan ulang).

Misalnya, di bagian atas Anda .htaccess(atau di mana pun Anda mencoba ini):

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^ /test.php?var=%{REQUEST_URI} [NE,R,L]

Membuat test.phpfile dummy untuk menghindari sub-permintaan internal ke dokumen kesalahan.

1 zzzaaabbb May 31 2019 at 16:12

Saya tidak dapat menentukan mengapa konfigurasi server atau kode situs memaksa perintah tanggapan '410 Gone' di htaccess diganti dengan tanggapan 404, jadi harus melakukan sesuatu seperti ini untuk memberi tahu googlebot agar berhenti berburu file CSS / JS yang dihapus secara berkala (dan diganti namanya saat dibuat ulang).

di .htaccess:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule v_(.*)_(.*)$ /410response.php [L]

di 410response.php ditempatkan di root:

<?php header($_SERVER['SERVER_PROTOCOL'].' 410 Gone');

PEMBARUAN I

Tanggapan 404 ketika mencoba menggunakan htaccess untuk perintah 410 dipaksa oleh server, karena server tampaknya memiliki dokumen 410 tersuai, yang tampaknya dirutekan ke 404. Menambahkan perintah untuk mencegahnya kemudian mengizinkan penggunaan htaccess dengan benar untuk mengembalikan 410 untuk kecocokan pola di RewriteRule. (Saya pikir saya sudah memeriksa kemarin untuk melihat apakah ini akan berhasil, karena @MrWhite mengatakan dalam jawabannya di atas untuk mengontrol server yang mungkin memiliki 410 kustom; hari ini ketika melakukan pemeriksaan ini, itu berfungsi dan menunjukkan bahwa server 410-to -404 pengalihan menimpa petunjuk 410 saya.)

ErrorDocument 410 default
RewriteRule test\.txt$ - [NC,R=410]

MrWhite! Saya menemukan solusi ini di salah satu posting Anda di Stack Exchange.