2

私はこの一日を成功せずに修正しようとしているので、誰かが私を助けてくれることを願っています。にアプリがありhttp://localhost/、ホスティングしているアプリにPylonsを使用しています。それに加えて、PHP / MySQLサイトをホストする必要があるため、Apacheも使用する必要がありました。

私の現在の設定では、Apacheバックエンドのこの構成でhaproxyを使用しています。

backend apache

mode http
timeout connect 4000
timeout server 30000
timeout queue 60000
balance roundrobin

server app02-8002 localhost:8002 maxconn 1000

これはこれによってトリガーされます:

acl image url_sub images
use_backend apache if image

したがって、IP /イメージを開くと、それがトリガーされ、ポート8002でApacheが開きます。

Apacheの場合、仮想ホストを作成しました。これは「イメージ」ホストです。

<VirtualHost *:8002>
 ServerAdmin my@email.com
 ServerName image
 ServerAlias image
 DocumentRoot /srv/www/image/public_html/
 ErrorLog /srv/www/image/logs/error.log
 CustomLog /srv/www/image/logs/access.log combined
</VirtualHost>

つまり、すべてうまく機能します。IP/ imagesと入力すると、/ srv / www / image/public_htmlが開きます。しかし、その後、問題が発生します。画像アップロードスクリプトを使用しているため、多くの書き換えが必要になるため、そのmodを有効にする必要がありました。これは、public_html / imagesフォルダーにある.htaccessです(URLをpublic_htmlの実際の場所と「一致」させるために、このサブフォルダーも作成する必要がありました。SetEnvPHP_VER 5_3

RewriteEngine On
# You must define your installation directory and uncomment the line :
RewriteBase /images/

RewriteRule ^([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=original&a=$1&e=$2 [L]
RewriteRule ^(icon|small|medium|square)\/([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=$1&a=$2&e=$3 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) application.php?request=$1 [L,QSA]

したがって、基本的に、これは機能していません。この仮想ホスト、サブディレクトリ、書き換えなどの間に競合があると思いますが、それを分離することはできないようです。

IP / images / xxxx.jpgを開くと、public_html / images / upload / originalフォルダーにある画像が開くので、書き換えが機能しているのは少し紛らわしいです。他のルールは機能していないようです。すべてのサムネイルと小さいバージョンが適切にレンダリングされていないため(アイコン、小、中、正方形)、サイトは非常に使用できなくなります。

開発サーバーのリンクは次のとおりです。http://localhost/images/

お時間を割いてご協力いただき、誠にありがとうございます。

4

1 に答える 1

1

最初に行う必要があるのは、書き換えられたフォームを介して失敗したURLの1つに直接アクセスし、期待される結果が得られることを確認することによって、mod_rewriteが実際に問題の一部であるかどうかを判断することです。

実際、問題は、元のサイズのPHPスクリプトでは機能するのに対し、小さい解像度のPHPスクリプトは「機能しない」ということかもしれません。次のURLの最初のものは、私に画像をうまく提供してくれました。2つ目は、同じ画像の小さいバージョンを提供することになっていますが、HTTP500を提供してくれました。

http://106.186.21.176/images/controller/Resizer.php?m=original&a=q&e=png  
http://106.186.21.176/images/controller/Resizer.php?m=small&a=q&e=png

問題の説明と一致する、投稿に記載されている小さいサイズのフォーマット名のいずれについても同じ結果(HTTP 500)が得られました。

スクリプトが期待どおりに機能することを確認したら、問題はmod_rewriteにある可能性があります。その場合は、リライトロギングを有効にします。RewriteLogディレクティブを使用してアクティブにし、RewriteLogLevelを使用してその詳細度を制御します。特により高いログレベルでは、それが何をしているのかについての非常に詳細な情報を提供することができます。これにより、ログから問題がすぐに明らかになるはずです。

また、可能であれば、.htaccessファイルでmod_rewriteルールを構成しないようにしてください。代わりに、それらをメインサーバーの構成ファイルに移動してください。その理由は、 Apachemod_rewriteの技術的な詳細のセクション「APIフェーズ」で説明されています。

信じられないほど、mod_rewriteは、ディレクトリごとのコンテキスト、つまり.htaccessファイル内でURL操作を提供しますが、URLがファイル名に変換されてから非常に長い時間がかかります。.htaccessファイルはファイルシステムに存在するため、この方法である必要があります。したがって、処理はすでにこの段階に達しています。言い換えると、現時点でのAPIフェーズによると、URL操作には遅すぎます。この鶏が先か卵が先かという問題を克服するために、mod_rewriteはトリックを使用します。ディレクトリごとのコンテキストでURL /ファイル名を操作すると、mod_rewriteは最初にファイル名を対応するURLに書き換えます(通常は不可能ですが、以下のRewriteBaseディレクティブを参照してください。これを達成する)そして、新しいURLで新しい内部サブリクエストを開始します。これにより、APIフェーズの処理が再開されます。

繰り返しますが、mod_rewriteは、この複雑な手順をユーザーに対して完全に透過的にしようとしますが、ここで覚えておく必要があります。サーバーごとのコンテキストでのURL操作は非常に高速で効率的ですが、ディレクトリごとの書き換えは、この鶏肉と卵の問題のために遅くて非効率的です。 。しかし一方で、これはmod_rewriteが平均的なユーザーに(ローカルで制限された)URL操作を提供できる唯一の方法です。

一般に、.htaccessをまったく使用しないことには、Apacheに機能をまとめて無効にすることさえしないように指示できるという追加の利点があります。これにより、Apacheが提供する各ディレクトリレベルで.htaccessファイルをスキャンする必要がなくなります。

于 2012-12-22T22:13:53.217 に答える