Re^2: HTTP POST

POST requests are meant for activities that change the status of a server in some way, so normally a POST request is handled by some sort of CGI script

There are other legitimate reasons to use POST over GET, even when you're not changing state.

For instance, if doing user authentication, if we were to send the password and other authentication information via a GET, it could be cached, making it a problem on public machines (eg, computer labs in schools). Now, in this case, most people don't link to a static file directly, but indirectly through some program that handles the authentication and authorization layers, but it could be handled by apache filters instead of a CGI or similar.

If you're trying to support older clients that don't correctly handle cache control headers (not as big an issues these days), and you don't want them to cache the content, forcing a POST request can get around the issue.

...

But I agree with not revealing file extensions if you don't have to -- it then requires URL rewriting it you decide down the road that you're going to change the backend, and the host requires file extensions to correctly process the files.

Comment on Re^2: HTTP POST

Replies are listed 'Best First'.
Re^3: HTTP POST by moritz (Cardinal) on Mar 10, 2008 at 14:59 UTC
For instance, if doing user authentication, if we were to send the password and other authentication information via a GET, it could be cached, One of the reasons it should not be cached is that authentication does change state on the server - it usually creates a session, and stores the "this user is logged in" information in the session. Of course security is another reason, but your example shows that not all state changes are obvious ;-)	[reply]

Replies are listed 'Best First'.

Re^3: HTTP POST
by moritz (Cardinal) on Mar 10, 2008 at 14:59 UTC

For instance, if doing user authentication, if we were to send the password and other authentication information via a GET, it could be cached,

One of the reasons it should not be cached is that authentication does change state on the server - it usually creates a session, and stores the "this user is logged in" information in the session.

Of course security is another reason, but your example shows that not all state changes are obvious ;-)

[reply]