Free http put software for linux

lns.http is a simple framework for writing Common Lisp web applications. The project handles the incoming connections, parses HTTP headers and queries, and finally hands control over to your URL handler.

lns.http is a HTTP/1.1 compatible web server but tries to achieve compatibility with lesser (down to the informal HTTP/0.9) clients.

The lns.http web server uses lisp-network-server to take care of network handling.

This software is licensed unter the LGPL.

HTTP::DAV is a WebDAV client library for Perl5.
SYNOPSIS
# DAV script that connects to a webserver, safely makes
# a new directory and uploads all html files in
# the /tmp directory.
use HTTP::DAV;
$d = new HTTP::DAV;
$url = "http://host.org:8080/dav/";
$d->credentials( -user=>"pcollins",-pass =>"mypass",
-url =>$url, -realm=>"DAV Realm" );
$d->open( -url=>"$url )
or die("Couldnt open $url: " .$d->message . "n");
# Make a null lock on newdir
$d->lock( -url => "$url/newdir", -timeout => "10m" )
or die "Wont put unless I can lock for 10 minutesn";
# Make a new directory
$d->mkcol( -url => "$url/newdir" )
or die "Couldnt make newdir at $urln";
# Upload multiple files to newdir.
if ( $d->put( -local => "/tmp/*.html", -url => $url ) ) {
print "successfully uploaded multiple files to $urln";
} else {
print "put failed: " . $d->message . "n";
}
$d->unlock( -url => $url );
Main features:
- Full RFC2518 method support. OPTIONS, TRACE, GET, HEAD, DELETE, PUT, COPY, MOVE, PROPFIND, PROPPATCH, LOCK, UNLOCK.
- A fully object-oriented API.
- Recursive GET and PUT for site backups and other scripted transfers.
- Transparent lock handling when performing LOCK/COPY/UNLOCK sequences.
- http and https support (https requires the Crypt::SSLeay library). See INSTALLATION.
- Basic AND Digest authentication support (Digest auth requires the MD5 library). See INSTALLATION.
- dave, a fully-functional ftp-style interface written on top of the HTTP::DAV API and bundled by default with the HTTP::DAV library. (If youve already installed HTTP::DAV, then dave will also have been installed (probably into /usr/local/bin). You can see its man page by typing "perldoc dave" or going to http://www.webdav.org/perldav/dave/.
- It is built on top of the popular LWP (Library for WWW access in Perl). This means that HTTP::DAV inherits proxy support, redirect handling, basic (and digest) authorization and many other HTTP operations. See LWP for more information.
- Popular server support. HTTP::DAV has been tested against the following servers: mod_dav, IIS5, Xythos webfile server and mydocsonline. The library is growing an impressive interoperability suite which also serves as useful "sample scripts". See "make test" and t/*.

This package provides a complete http client library. It currently implements most of the relevant parts of the HTTP/1.0 and HTTP/1.1 protocols, including the request methods HEAD, GET, POST and PUT, and automatic handling of authorization, redirection requests, and cookies.

Furthermore the included Codecs class contains coders and decoders for the base64, quoted-printable, URL-encoding, chunked and the multipart/form-data encodings. The whole thing is free, and licenced under the GNU Lesser General Public License (LGPL) (note that this is not the same as the GPL).

Following are the kits and documentation for the HTTPClient Version 0.3-3. If you have any problems, bugs, suggestions, comments, etc. see the info on debugging and reporting problems. An older version of these pages are also available in Japanese, thanks to the kindly efforts of Yuji Kumasaka.

Using the HTTPClient should be quite simple. First add the import statement import HTTPClient.*; to your file(s). Next you create an instance of HTTPConnection (youll need one for every server you wish to talk to). Requests can then be sent using one of the methods Head(), Get(), Post(), etc in HTTPConnection.

These methods all return an instance of HTTPResponse which has methods for accessing the response headers (getHeader(), getHeaderAsInt(), etc), various response info (getStatusCode(), getReasonLine(), etc), the response data (getData(), getText(), and getInputStream()) and any trailers that might have been sent (getTrailer(), getTrailerAsInt(), etc). Following are some examples to get started.
To retrieve files from the URL "http://www.myaddr.net/my/file" you can use something like the following:
try
{
HTTPConnection con = new HTTPConnection("www.myaddr.net");
HTTPResponse rsp = con.Get("/my/file");
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
data = rsp.getData();

rsp = con.Get("/another_file");
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
other_data = rsp.getData();
}
catch (IOException ioe)
{
System.err.println(ioe.toString());
}
catch (ParseException pe)
{
System.err.println("Error parsing Content-Type: " + pe.toString());
}
catch (ModuleException me)
{
System.err.println("Error handling request: " + me.getMessage());
}

This will get the files "/my/file" and "/another_file" and put their contents into byte[]s accessible via getData(). Note that you need to only create a new HTTPConnection when sending a request to a new server (different protocol, host or port); although you may create a new HTTPConnection for every request to the same server this not recommended, as various information about the server is cached after the first request (to optimize subsequent requests) and persistent connections are used whenever possible (see also Advanced Info).

To POST form data from an applet back to your server you could use something like this (assuming you have two fields called name and e-mail, whose contents are stored in the variables name and email):
try
{
NVPair form_data[] = new NVPair[2];
form_data[0] = new NVPair("name", name);
form_data[1] = new NVPair("e-mail", email);

// note the convenience constructor for applets
HTTPConnection con = new HTTPConnection(this);
HTTPResponse rsp = con.Post("/cgi-bin/my_script", form_data);
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
stream = rsp.getInputStream();
}
catch (IOException ioe)
{
System.err.println(ioe.toString());
}
catch (ModuleException me)
{
System.err.println("Error handling request: " + me.getMessage());
}

Here the response data is read at leisure via an InputStream instead of all at once into a byte[].

As another example, if you want to upload a document to a URL (and the server supports http PUT) you could do something like the following:
try
{
URL url = new URL("http://www.mydomain.us/test/my_file");

HTTPConnection con = new HTTPConnection(url);
HTTPResponse rsp = con.Put(url.getFile(), "Hello World");
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
text = rsp.getText();
}
catch (IOException ioe)
{
System.err.println(ioe.toString());
}
catch (ModuleException me)
{
System.err.println("Error handling request: " + me.getMessage());
}

HTTP::Async is a Perl module that can process multiple HTTP requests in parallel without blocking.

SYNOPSIS

Create an object and add some requests to it:
use HTTP::Async;
my $async = HTTP::Async->new;

# create some requests and add them to the queue.
$async->add( HTTP::Request->new( GET => http://www.perl.org/ ) );
$async->add( HTTP::Request->new( GET => http://www.ecclestoad.co.uk/ ) );
and then EITHER process the responses as they come back:
while ( my $response = $async->wait_for_next_response ) {
# Do some processing with $response
}
OR do something else if there is no response ready:
while ( $async->not_empty ) {
if ( my $response = $async->next_response ) {
# deal with $response
} else {
# do something else
{
}
OR just use the async object to fetch stuff in the background and deal with the responses at the end.
# Do some long code...
for ( 1 .. 100 ) {
some_function();
$async->poke; # lets it check for incoming data.
}

while ( my $response = $async->wait_for_next_response ) {
# Do some processing with $response
}

Although using the conventional LWP::UserAgent is fast and easy it does have some drawbacks - the code execution blocks until the request has been completed and it is only possible to process one request at a time. HTTP::Async attempts to address these limitations.

It gives you a Async object that you can add requests to, and then get the requests off as they finish. The actual sending and receiving of the requests is abstracted. As soon as you add a request it is transmitted, if there are too many requests in progress at the moment they are queued. There is no concept of starting or stopping - it runs continuously.

Whilst it is waiting to receive data it returns control to the code that called it meaning that you can carry out processing whilst fetching data from the network. All without forking or threading - it is actually done using select lists.

Socks via HTTP provides a socks tunnel via HTTP.

Socks via HTTP is a program converting SOCKS requests into HTTP requests and tunnelling them through HTTP proxies if needed.

The SOCKS protocol allows programs to traverse firewalls on any port number and is used by many popular programs, like Napster, MSN Messenger, CRT(telnet client) and many others.

Many companies restrict firewall traversals only to HTTP requests, disabling SOCKS proxy.

Socks via HTTP provides a miniature SOCKS server for the SOCKS client, performing its connection through an HTTP proxy to a remote server, which establishes the real connection.

Socks via HTTP is 100% Java, and can run on any OS. It is entirely written in Java.

HTTP Navigator provides a set of PHP classes to simplify sending and receiving HTTP messages.
HTTP Navigator is a set of PHP classes, based on Perls LWP, that simplifies sending and receiving HTTP messages. Features include: cookie handling, basic authentication, chunked encoding, and keep-alive.
Main features:
- Cookie tracking (Cookie Jar class in 2.0)
- Gzip support (as of 2.1)
- File uploads (multipart/form-data support as of 2.1)
- Proxy support
- Connection caching (as of 2.0)
- Chunked Encoding (as of 2.0)
- Basic Authentication
- Auto redirects
- CURL support
- SSL support (through CURL)
Enhancements:
- HTML head parsing
- a new option for lax redirect support (for 302 respones)
- bugfixes in the Protocol_CURL class
- handling of an unexpected 100-Continue response in Protocol_HTTP
- some minor bugfixes

PHKP is an implementation of the OpenPGP HTTP Keyserver Protocol (HKP) in PHP. It allows people to serve a PGP keyserver on most webservers, provided that the webserver has GnuPG and PHP with exec() enabled. Searching, requesting and submitting (optional) of keys are all supported.

The development version of PHKP is available in my Darcs repository:
darcs get http://el-tramo.be/darcs/phkp

Alternatively, you can download the latest release. Instructions on how to use PHKP can be found in the README of the source tarball.

WARNING: This is software is not production-ready. It probably contains bugs and security leaks. Use at your own risk !!!

Installation:

Copy the phkp.php script to your webserver directory. If you can put it in the root directory of your web dir, you can rename it to index.php. If you dont do this, you will need to redirect every request to /pks to this script. For example, using Apache rewrite rules:

RewriteRule ^/pks/(.*) /phkp.php?/pks/$1

Modify the values in index.php to reflect your settings and create the necessary directories

Usage;

Simply point your gpg to the right keyserver and port. For example:

gpg --keyserver hkp://example.com:80 --search-keys Remko
gpg --keyserver hkp://example.com:80 --send-keys 8E041080
gpg --keyserver hkp://example.com:80 --recv-keys 8E041080

Known Issues:

Expiration and revocation is only detected with the english version of GnuPG. Other languages will omit this information.