I planned to receive it some way in my perl script without using a webserver...

What's your problem with HTTP? Is that really what you are trying to avoid? Please tell us what the issue really is.

which sends its output via a html form with post method

Sends it how? Via HTTP? As long as you use HTTP, you'll need an HTTP server (aka web server).

If you do want to use HTTP, it doesn't mean you have to use apache or IIS. It could be something written in Perl (say like HTTP::Server::Simple). Your script doesn't even need to be persistent if you use inetd.

If you don't want to use HTTP, you'll have to find some alternate means of communicating the request from JS on one machine to a perl process on another machine. Your options are quite limited, unless you have limited setup. Perhaps you could provide us with more information about your setup.

I planned to receive it some way in my perl script without using a webserver

The hard answer is that you have to setup a server listening on port 80, figure out how to parse HTTP headers, and when it is a POST, do the right thing. But then, why would you do all that when a web server, perl, and CGI modules will do this for you and have been extensively tested?

The hard answer is that you have to setup a server, i.e. a program written by the op, listening on port 80, figure out how to parse HTTP headers, and when it is a POST, do the right thing.

Ahh. I hadn't thought of that.

I guess the author assumes having this running within a webserver...

You can transfer data directly from one program to another program using sockets, which is not exactly an easy subject to learn, but a js script cannot open up a socket. So it is more than likely that you are very confused about what you want to do--or you are trying to do something that is specifically prohibited by js scripts for security reasons.

The article you read is trying to show how a perl script can get form information from a web server without using the assistance of any perl modules, like CGI.pm. In contrast, the CGI.pm module saves you from having to parse the information by hand. The CGI.pm module does the parsing for you and puts the form information in a global hash, where the keys are the names of the form input elements, and the values are what the user entered in those input elements. You can parse the data yourself or use the CGI module to parse the data for you--but in both cases a web server has to process the form data first, then pass it to the perl script.

Philosophically speaking, you need a "web server", but not necessarily something with the full capacity.

If you care socket programming, just write a piece of simple program, listening at port 80 (or whatever), receiving incoming HTTP post request, processing it, and responding to it.

Or use something like LWP.

Thought so about the webserver thing, I like the last post and I think I will try it in this direction first, its no time pressure behind that and I would like to explore it...

The whole story behind that is that I planned to tie a short javascript to a brwoser shortcurt which gets the url of the site im currently at and write it into a file or whatever... (just for keeping bookmarks) but when I discovered that javascript don't have such a function due to security reasons I try it to send via http now...

Ajax can help in this case, and to make things easier, more stable, and more cross platform, try a javascript library, for example jquery.

Peter (Guo) Pei

Not at all. You could receive an HTTP POST request as an HTTP::Request object, via CGI, etc. You just can't receive it over HTTP without an HTTP/web server.

That fragment of an article without context used to be say it was written in May 14, 2001. Hand parsing CGI the way that article suggests has been a bad idea since 1993.

I would avoid that domain entirely in the future, the information if of very low quality, and always without context.