A state machine really isn't a great design for a web app.
For HTTP to work best, you should try and keep it as stateless as possible. Keeping state consistent between multiple servers is very much non-trivial. If your web app takes off and needs to be scaled to more than 1 server, design choices such as state machines can really cause you very nasty issues down the line. You either have to keep state across a memcache system, which can get wonky with multiple requests hitting multiple servers, or you have to keep the state encoded inside a cookie which opens up security issues.
Sticking to stateless webapps is nearly always a better choice. Check out some guides to RESTful services to get started.
You likely don't want to use a state machine to manage the state of the application here, but there are many other places a state machine comes in handy. If one of your models has several boolean variables, it may benefit from a state machine. Even HTTP parsing itself is often done with a state machine. None of those impact the statelessness of the connections.
Definitely not for application state, but for resource state, a FSM can be invaluable. Take for instance something as simple as a blog comment system, where any administrator needs to be able to transition a "comment" resource into either accepted or rejected states.
They also work great for transactional resources like a shopping cart order.