|
Re: HTTP POST
by zentara (Cardinal) on Mar 10, 2008 at 16:14 UTC
|
Must Perl only POST to .pl files?That's not true at all. Google for "cgi post vs get", or see get vs post .So you can post to a script in any language. The thing about a post, is that it contains a message body after the header, usually a file encoded for upload. Now, the rumor you heard that only a .pl file can accept a post, is just confusion over how the web server is setup. You can configure a web server, so that perl scripts must end in .pl, but it is not a hard-and-fast rule, some servers are setup so that scripts must end in .cgi. Basically, a GET request contains all information in the url string that is sent, while a POST sends a url string, followed by a block of encoded information, which is usually the file.
Now a script can be written to NOT allow posts, as a security measure,
so that may be the source of your first error. If a script does allow posts. it needs permissions to write the file on the server. Usually you need to write to a directory with 777 permissions, since a webserver usually runs with the lowest of permission levels, like "user:nobody, group:nobody". You can test posting with this script, which will print out whatever you post to it. Name it showpost.cgi or showpost.pl
#!/usr/bin/perl -wT
use strict;
my $buffer;
read (STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
print "Content-type: text/plain\n\n";
print $buffer;
| [reply]
[d/l] |
Re: HTTP POST
by Corion (Patriarch) on Mar 10, 2008 at 14:27 UTC
|
The error HTTP/1.1 500 Internal Server Error means that some internal error occurred. Look in the web server error log to find a more detailed error description.
Most likely, you have an error in your receiving Perl program.
As for the terminology - you don't "POST to a file" on a webserver, you "send a POST request to an URL on a webserver". That URL is commonly handled by a program, and it does not matter in what language that program is written.
| [reply]
[d/l] |
|
|
Maybe I got the basic concept wrong. Isn't POST about the same a 'write'? I want to write a message from my PC over the internet, to a file on a webserver.
And the final goal, there is a file (.txt) that I just want to zero out. After reading the info remotely I want to empty it and then write an new record in it.
I'm off studying.
UPDATE: # The request URI is not a resource to retrieve; it's usually a program to handle the data you're sending.
| [reply] |
|
|
POST requests don't modify files on the server, unless you write a server side script that modifies them.
Maybe you're confusing it with the PUT request that is used for example in WebDAV?
| [reply] |
|
|
A post is not going to write to a file, a post sends data to a program that then does something with it.
what it sounds like you need to do is write a Perl program on your server, that will accept the data, then write it to your .txt file.
| [reply] |
|
|
Re: HTTP POST
by moritz (Cardinal) on Mar 10, 2008 at 14:28 UTC
|
The URL doesn't have to be tied to file type that handles it.
It's no problem to have a perl script handle a URL that ends in /x.txt - usually I don't show any file extensions for HTML files because I don't think the user should be bothered with implementation details.
But of course it doesn't make any sense to send a POST request to static file. 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. | [reply]
[d/l] |
|
|
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.
| [reply] |
|
|
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] |