PHP(5.2.9-1)アプリケーションでIIS(Microsoft-IIS/6.0)がPOST時に次のエラーをスローする原因となる1つのフォームがあります:
アクセスしようとして無効なメソッド(HTTP動詞)が使用されたため、探しているページを表示できません。
これはHTTP 405ステータスコードです。アプリケーションの他のすべてのフォームが機能するため、IIS 'verbs'のPHPページが正しい。
これは顧客のサーバーであり、設定の検証やコードのテストのためにアクセスすることはできません。私にできることは、顧客交換ファイルを送信することだけです。 IISサーバー上の他の顧客にはこのような問題はありません。
フォームは完全に簡単です:
<form method="post" action="index.php">
... fields ...
</form>
IISが1つのフォームでのみエラーをスローし、他のフォームでは正常に動作する原因は何ですか?
顧客のサーバーへのFTPアクセスを取得することができたため、問題を追跡できました。
フォームがPOSTされた後、ユーザーを認証し、アプリの主要部分にリダイレクトします。
Util::redirect('/apps/content');
エラーはフォームの投稿ではなく、その直後のリダイレクトで発生していました。何らかの理由で、IISは引き続きリダイレクトのためにPOSTメソッドを仮定し、その後にPOST /apps/content
はディレクトリなので。
エラーメッセージは、エラーを生成していたのは次のページであることを決して示しませんでした-ありがとう、Microsoft!
解決策は、末尾にスラッシュを追加することでした:
Util::redirect('/apps/content/');
IISは、ディレクトリへのPOSTを試行しなくなったため、デフォルトドキュメントへのリダイレクトを解決できました。
VB6を展開していますIIS 75個のフォルダーを持つリモート専用サーバーにアプリケーション。そのフォルダをヒットしても、どのページをサーバーにアップするかわからなかったため、このスレッドで言及されているエラーがスローされました。
許容される動詞は、web.config(Webサイトのルートにある)で<system.web><httpHandlers>
および場合によっては<webServices><protocols>
。 Web.configが存在する場合、アクセスできます。おそらくないグローバルなserver.configもあります。これらのいずれかを見ることができれば、手がかりを得ることができます。
許容される動詞はコンテンツタイプによって異なる場合があります。ページにContent-typeヘッダーを設定していますか? (つまり、Content-typeがapplication/jsonの場合、異なる動詞が許可されます)
たぶん、あなたはPOST vs post?このサポート記事は、IISで問題を引き起こす可能性があることを示唆しています: http://support.Microsoft.com/?id=828726 =
理由はわかりませんが、POST
メソッドによってページ内のフォームを自分自身に送信したときに発生しました。
したがって、method="post"
からmethod="get"
または削除action="anyThings.any"
あなたの<form>
タグ。
フォームのPOST=をGETに変更しなければなりませんでした。テストAzureサイトのhtmlページにデモを投稿していました。詳細はこちらをご覧ください: http:/ /support.Microsoft.com/kb/942051
私たちはちょうどこの同じ問題に出くわしました。 CpanelはPHPのみPHP and .NETに拡張され、デフォルトは.NETになりました。
Cpanelにログインし、同じ問題がないことを確認します。
ドリューム自身が言ったように、これはPOSTがスクリプトに実際に成功した後の後続のリダイレクトによるものです。(これをコメントにコメントとして追加したかもしれませんが、コメントするには50の評判が必要です。そして、私はここで新しいラウンドです-ダフトルール私見)
ただし、ディレクトリだけでなくページにリダイレクトしようとしている場合にも適用されます-少なくとも私にとってはそうでした。 /thankyou.htmlにリダイレクトしようとしていました。これを修正するのは、絶対URL、つまり http://example.com/thankyou.html を使用することです
ファンページタブ用に開発していたFacebookアプリケーションでこの問題が発生しました。 Facebookアプリケーションでこの問題に直面した場合
1-goto https://developers.facebook.com
2-開発中のアプリケーションを選択します
3-アプリケーションへのすべてのリンクに末尾のスラッシュ/があることを確認します
私の問題は https://developers.facebook.com- > Apps-> MYAPPNAME-> settings-> Page Tab-> Secure Page Tab URL、Page Tab Edit URL、Page Tab URL hopeにありましたこれは役立ちます
サーバーがPOSTリクエスト(getおよびpostは動詞))の処理に問題があるように聞こえます。解決策は、サーバーを修正するか、取得リクエストを使用するようにアプリを変更することです。