Whilst it may not be best practice you can serve one set of html for an Http Get action and another for the Http Post action. Your get action can return the form and the response to the post action could return your second page.
There are a number of reasons that this is a bad idea, these include
- Http Post is meant to cause a state change, not guard access to a
page
- It is easily defeated with any sort of proxy or rest client
- Navigation in the browser may behave unexpectedly
- The user would have to fill in the form for each visit.
It is far better to come up with an alternative solution like generating a temporary access token or setting a cookie to say that they have completed the form.
The best solution is perhaps up for debate, but a simple is solution is to have two .php pages Let's call them index.php
and form.php
. Your web server is configured to serve up index.php
when a GET
request is made to www.example.com
. (The exact method to do this will depend on your server software).
index.php
checks for a cookie and redirects to form.php
if the cookie is not set. See this question/answer for more details
form.php
responds to a GET
request by serving the html for the form and to a POST
request by setting the cookie and redirecting back to index.php
.