4

次のような URL に POST データを送信する基本的な MVC システムがあります。

管理者/製品/追加/

しかし、これは私にエラーを与えています

禁断

このサーバーの /admin/product/add/ にアクセスする権限がありません。

さらに、ErrorDocument を使用して要求を処理しようとしたときに、404 Not Found エラーが発生しました。

RewriteRule は単純です

RewriteRule ^(.*)/$ index.php?uri=$1

前回サーバーでこれを見たとき、ファイル/ディレクトリのアクセス許可を 755 に変更すると修正されたように見えましたが、今回はそうではありませんでした。エラーの理由を本当に理解したことがないので、誰かがさらに情報を提供できることを望んでいましたか?

4

3 に答える 3

9

2つのエラーがあります：

  1. このサーバーの/admin/ product /add/にアクセスする権限がありません。
  2. さらに、ErrorDocumentを使用してリクエストを処理しようとしたときに、404NotFoundエラーが発生しました。

2つ目は、確かに同じバグの結果です。Apache構成に、デフォルトのhttpサーバー処理から404エラーを削除し、それをphpアプリケーションにプッシュするものがあるかもしれません。このphpアプリケーションが機能していれば、素晴らしい404が得られますが...

1つ目は、phpアプリケーションがまったく実行されていないことを示しています。

それで。この最初のエラーは、apacheがサーバー上のディレクトリに直接アクセスし、そのリストを作成しようとしたことを示してい/path/to/documentroot/admin/product/add/ます（ディレクトリコンテンツのリストは、apacheが許可されている場合にのみ実行されます）。しかしもちろん、これはサーバー上の実際のディレクトリではありません。これは、アプリケーションの仮想パスです。したがって、apacheは404で終了します（これはエラー2につながります）。

アプリケーションは仮想パスを処理しますが、apacheはそれを管理しません。RewriteRuleジョブは、apacheがパスを提供しようとする前index.phpに要求されたパスをキャッチし、クエリ文字列引数として1つの単一のphpファイル（）に渡すことです。

したがって...この書き換えルールは適用されませんでした。このルールの適用を妨げる可能性のあるものはたくさんあります。

  1. mod_rewriteがアクティブ化されていません：モジュールが存在し、有効になっていますか（RewriteEngine on）？
  2. 構文エラー：mod rewrite構文は非常に読みにくく、時には非常に複雑です。しかし、ここでは非常に単純に見えます。
  3. RewriteRuleの結果のファイルは、apacheの有効なターゲットではない可能性があります。index.phpファイルがDocumentRootに存在しない場合、またはapacheユーザーが読み取れない場合、apacheは失敗します。警告：apacheユーザーがファイルを読み取り可能にするということは、ファイルに対する読み取り権限だけでなく、apacheユーザーのすべての 親ディレクトリーに対する実行権限も持つことを意味します。これはあなたの古典的な/解決策が問題を修正しているところです。chmodchown
  4. ルールは有効な構成ファイルに含まれている必要があります。このルールは、場所またはディレクトリセクション内のapache構成ファイルにありますか？または、グローバルスコープ内にある可能性があります-これにより、書き換えルールの構文が変更される可能性があります-。それとも.htaccessファイルにありますか？.htaccesの場合、apacheは.htaccesファイルを読み取り、そこで許可されているmod-rewrite命令です（AllowOverride None）。他の.htaccessファイルが優先されていませんか？

したがって、問題を修正するには：

  • 2.2.16を超えるApacheバージョンを使用している場合は、RewriteRuleをFallbackRessource /index.phpに置き換えて、これがmod-rewriteの問題によるものではないことを確認できます。
  • 少なくともこのファイルへの直接リクエストが機能するように、直接リクエストしてみてくださいindex.php
  • documentRootの有効なリソースに直接アクセスしてみてください（txtファイル、画像、書き換えでは処理されないが直接提供されるもの）
  • 仮想パスのいずれかが実際の物理パスをマップできるかどうかを確認します。Apacheは物理パスを提供しようとはしていませんが（を記述した場合のようにRewriteCond %{REQUEST_FILENAME}-d）、実際にパスをindex.php
  • Apacheエラーログを確認してください。
  • RewriteLogおよびを使用してmod_rewriteをデバッグしますRewriteLogLevel
  • ファクト、設定、テストを収集し、それをSOまたはServfaultにプッシュします。

したがって、問題は非常に単純です。phpアプリケーションがリクエストを受信して​​いません。しかし、この状態で終了する方法は非常にたくさんあります。メッセージ自体はそれほど重要ではありません。エラーを見つける唯一の方法は、すべてのパラメーターをチェックすることです（または、長年のバグ修正の経験があり、管理者のように、ランプのバグ（通常はあごひげ）の認知前の直感的な器官を開発します）。そして、私たちがあなたを助ける唯一の方法は、構成の詳細の大きなリストから奇妙な事実を見つけることです。これが、これらの情報がすべてあなたにとって単に「古典的」に見えても、良い質問には多くの情報が含まれている理由です。

編集

問題を明確にするには、回答を編集するか、POST ChromeデベロッパーツールやFirebugなどのツールを使用してリクエストを追跡するか（ネットワーク追跡を記録モードにして複数のPOSTをキャッチする）、LiveHTTPヘッダー応答を使用して投稿を再生してみてください。問題のあるPOSTを特定し、詳細をお知らせください。デバッグは魔法ではありません。

今、私は1つの魔法のランダムPOST失敗を知っています。これは空のGETURLバグです。それはそうかもしれません（またはそうではありません）。空のGETURLがどこかに隠されている場合（たとえば<IMG SRC="">、url()css内、またはヘッダー内の空のLINK。これらの隠されたPOSTは、HTTPで「replay-the-request-which-launched-the-source-page」として定義されています。一部のブラウザは、ページが見つかった場合にページを提供するPOSTを再生することもあります。これにより、非表示のPOSTが破損する可能性があります。

POSTが適切なサーバーに送信されていない可能性もあります。言いにくい。したがって、コメントから情報を収集し、ネットワーク分析を追加して、実際には十分な事実が含まれていない質問を編集してください。

于 2013-01-20T22:45:05.283 に答える
1

これを使って：

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?uri=$1 [L]

また、www または非 www ドメインのみを使用し、同時に両方を使用しないでください。htaccess を使用してユーザーを目的の場所にリダイレクト...

非 WWW から WWW へ:

RewriteCond %{HTTP_HOST} !^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

WWW から非 WWW:

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^www\.(.*)$ http://%1/$1 [R=301,L]
于 2013-01-24T23:36:50.600 に答える
1

これを試して：

RewriteCond %{REQUEST_METHOD} =POST
RewriteRule ^(.*)/$ index.php?uri=$1
于 2012-12-10T20:54:01.817 に答える