本番サーバーでのみ、フォームの送信に失敗する

取り組んでいるプログラム概要

①お問い合わせフォーム(/contact/index.php)に情報を入力して、「送信内容の確認」ボタンを押下する。
②別ページ(/contact/confirmation/index.php)に移動して、入力内容を一覧で確認する。
③「送信」ボタンを押下すると、再び同じページ(/contact/confirmation/index.php)が呼び出され、問題なければthanksページへ遷移し、メールが送信される。

ざっくり言うと、このような挙動になるお問い合わせフォームを設計しています。

発生した問題

問題は③の手順で起こりました。フォームの記述内容を確認して、「送信」ボタンを押下すると、本来であれば問題がないのでthanksページへ移動してメールが送られる動きを期待していましたが、なぜかthanksページには移動せず、フォーム入力内容の一覧画面(/contact/confirmation/index.php)が再び表示され、尚且つPOST送信された値が空、つまり一覧に情報が一つもないテーブルが出力された画面に辿り着いてしまいました。

イメージ説明

そしてこの問題は、開発を行っているlocalhostや、練習用に用意しているエックスサーバー上では発生しません。一般公開に使用している、本番用エックスサーバーでのみ起こります。

たまたま回避できた方法

練習用のサーバーでOKだったので、大丈夫だろうと思って本番環境にアップロードしたところ、上記の大変な問題が起こりました。
そこでなんとか応急的に解決できないかと思い、勘で以下の❶〜❸を切り替えてみる実験を行いました。

PHP

1<!-- <form action="<?php echo h($_SERVER['SCRIPT_NAME']); ?>" method="POST"> -->2<!-- <form action="/contact/confirmation/index.php" method="POST"> -->3<form action="" method="POST">4<table>5<?php6// フォームの入力内容をテーブル形式で出力する処理。7echo generateConfirmingTable($_POST, $hiddenConfirmationFields, $sessionKeyForToken);8?>9</table>10 11<div>12 <button type="button" onClick="history.back()">戻る</button>13 <button type="submit">送信する</button>14</div>15</form>16 17<?php18$charset = "UTF-8"; 19function h($string)20{21 global $charset;22 return htmlspecialchars($string, ENT_QUOTES, $charset);23}24?>

当初記述していたコードは❶で、それが展開された後の値を直書きしたものが❷です。そして❸は、自分自身を呼び出すためにaction属性値を空にしてみました。

❶及び❷の状態だと、localhostや練習用サーバーでは問題が起こらないものの、本番環境では前述した問題が発生する状況に陥りました。

しかし、❸にしてみたところ、全ての環境にて問題なく、thanksページまで辿り着くことができ、メールの送信にも成功しました。

もちろん、他にも様々な処理を書いていますが、formのaction属性値を切り替えただけで状況が変わりましたので、原因はこの辺りにあると睨んでいます。

しかしながら、私にはどうして❶や❷がだめで、❸だけが動いているのかが分かりません。こういった不安があるため、今の状態のお問い合わせフォームが今後も正常に動いてくれているのか自信が持てないでいます。

この問題の原因をご存知の方はいらっしゃいますでしょうか。また、私の試した❸のアプローチは妥当な方法かどうかを教えていただけると幸いです。

参考にした情報

formのactionに自分自身を指定する方法
こちらの記事では、formのaction属性値に、自分自身のURLを記述するとエラーが起きた、とのお話が紹介されていました。

【MailForm01】PHP多機能メールフォーム フリー(無料)版
私が今回/confirmation/index.phpを作成するにあたり、ベースとして使用させていただいた無料配布プログラムがこちらです。
それを自己流で色々とカスタマイズいたしましたが、❶にて<?php echo h($_SERVER['SCRIPT_NAME']); ?>という処理を採用していたのは、こちらのプログラムにデフォルトでそう書かれていたためです(どういう意図でその記述になっているのかは分かりません)。

コメントを投稿

0 コメント