Free http headers software for linux

HTTP::Handle is a HTTP Class designed for streaming.

SYNOPSIS

use HTTP::Handle;

my $http = HTTP::Handle->new( uri => "http://www.google.com/" );
$http->connect();

my $fd = $http->fd();

while () {
print "--> $_";
}

The HTTP::Handle module allows you to make HTTP requests and handle the data yourself. The general ideas is that you use this module to make a HTTP request and handle non-header data yourself. I needed such a feature for my mp3 player to listen to icecast streams.

HTTP::Handle->new()

Create a new HTTP::Handle object thingy.

Arguments possible:

url => "http://www.google.com/"

Sets the initial URL to connect to.

follow_redirects => [ 0 | 1 ]

Automatically follow HTTP redirects. This defaults to true (1). Set to 0 to disable this.

http_request => HASHREF

Any thing put in here will be sent as "key: value" in the http request string.

$http->connect()

Connect, send the http request, and process the response headers.

This function returns -1 on failure, undef otherwise. The reason for failure will be printed to STDERR.

$http->fd()

Get the file descriptor (socket) were using to connect.

$http->url( [ url_string ])

Get or set the URL. If a url string is passed, you will change the url that is requested. If no parameter is passed, a URI object will be returned containing the

$http->follow_redirects( [ 0 | 1 ] )

If a value is passed then you will set whether or not we will automatically follow HTTP 302 Redirects. If no value is passed, then we will return whatever the current option is.

Defaults to 1 (will follow redirects).

$http->http_request_string()

Returns a string containing the HTTP request and headers, this is used when

$http->connect() is called.

Header Spy is an extension which shows HTTP headers on statusbar.
Main features:
- Up to 5 statusbar panels;
- Request and response headers;
- Custom headers;
- Tooltip headers;
- Menu with headers for statusbar panels;

HTTP::WebTest is a Perl module for testing static and dynamic web content.

SYNOPSIS

use HTTP::WebTest;

my $webtest = new HTTP::WebTest;

# run test from file
$webtest->run_wtscript(script.wt);

# or (to pass test parameters as method arguments)
$webtest->run_tests($tests);

Introduction

This module runs tests on remote URLs containing Perl/JSP/HTML/JavaScript/etc. and generates a detailed test report. This module can be used "as-is" or its functionality can be extended using plugins. Plugins can define test types and provide additional report capabilities. This module comes with a set of default plugins but can be easily extended with third party plugins.

The wt script is provided for running HTTP::WebTest from the command line.
The test specifications can be read from a parameter file in wtscript format or input as method arguments. The test results can be displayed on the terminal, directed to a file, stored in a scalar variable. The test results can also be emailed. The report can be modified and extended using report plugins.

Each URL/web file is tested by fetching it from the web server using a local instance of an HTTP user agent. The basic test is simply whether or not the fetch was successful. You may also test using literal strings or regular expressions that are either required to exist or forbidden to exist in the fetched page. You may also specify tests for the minimum and maximum number of bytes in the returned page. You may also specify tests for the minimum and maximum web server response time.

Data flow for HTTP::WebTest:

-------------- -------------
| | | |
| Input |------------->| WebTest |
| parameters | | |
| | -------------
-------------- | ^
| |
V |
------------- ------------
| | request | |
| Remote || user |
| | response | agent |
------------- | |
------------

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.

httpcmdd provides a way to have (web) browser user interface to programs running on the same machine as the browser. httpcmdd PEEKs the headers of the incoming message from browser and find program that matches the request received.

Programs are run with privileges of the user running the browser. Each user may have their private commands available in their home directory in addition to the common programs installed to the system (if any). There is also possibility to place some programs in special directory and programs residing there will be run with root privileges.

httpcmdd passes the socket it accepted to the program it started. httpcmdd did not read any data out of the socket, but just peeked it. Program gets all data send from the beginning and httpcmdd does not work as a proxy delivering the data; all data goes directly between peer and the program httpcmdd launched without anyone interfering.

httpdcmdd server socket is bound to the localhost loopback interface only thus network connections to httpcmdd server is not possible -- and if those were, httpcmdd would be unable to identify the user on peer, disallowing further message processing. Finally, some sanity checking is done to incoming http headers; for example Referer: header (if one) not matching to httpd ip (127[.0[.0]].1) and port will cause connection shutdown.

Installation and Usage

There is a set of example programs (shell, perl and python scripts) that can be used to test and get a clue of httpcmdd usage. Just run quicktest.sh to check out those examples (just like in Quick Start section at the beginning of this document). It leaves behind symbolic link at $HOME/.httpcmdd and running httpcmdd daemon. You may want to clean these up after initial testing period (Note that quickstart.sh-compiled httpcmdd binary file was unlinked soon after it was launched).

To compile httpcmdd daemon enter sh src/httpcmdd.c --prefix=/usr or sh src/httpcmdd.c --prefix=/usr/local at the command line. There is more options to give on command line; enter sh httpcmdd.c to see those if desired.

(Ive planned to create Makefile for future needs; that will come in time).

After compiled, enter ./httpcmdd (as root). If port 127.0.0.1:80 is unbound the daemon will start and detach from terminal. In that case you can try to connect to it by entering http://127.1/ on a browser window. That probably returns an error page (as there is no commands installed to provide content (unless you left the symbolic link generated by quicktest.sh laying around).

If the port 80 is bound (probably by apache http server) or you do no access to root privileges, httpcmdd can be started with option -p . In that case you can access httpcmdd with url http://127.1: /. If httpcmdd was started with user privileges other than root only that user can access the services httpcmdd provides; access to all other users will be denied by default error message and incident is logged to system log.

In case you want to install httpcmdd as a system service (started at system boot time) and you want to use port 80 for it (as I usually like to do) and you have other httpd servers on the system that binds both on localhost loopback interface (127.0.0.1) and on network interface, run httpcmdd first. With luck the other one will accept this and it works fine with other interfaces and skips 127.1. If not (or there is system limitations to do this automatically), you need to configure the other httpd to skip 127.1.

Bauk HTTP server project is a high-performance Web server. Bauks advanced architecture and unique design provide high performance and many original features, ie. ability to serve unlimited number of Virtual Hosts/simultaneous HTTP connections per single server process without performance loss.
Full installation requires only a single directory of UNIX file system used as a working directory for Bauk executable. Configuration process is simple and performed by adjustment of Bauk configuration script.
Main features:
- Full HTTP/1.1 and CGI/1.1 standard compliance
- HTTP authentication, Basic method, auth script per Virtual Host
- Unlimited number of Virtual Hosts without performance loss
- Virtual Host aliases
- Unlimited number of simultaneous HTTP connections per single Bauk process with no performance loss (Special Edition)
- Persistent (Keep-Alive) connections
- URL Path; define URL and path with type of access; ie. read, write, browse, execute, require HTTP authentication, etc.
- OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE methods of HTTP request defined by HTTP/1.1, configurable per URL Path
- Content negotiation by client language and charset
- Configurable MIME types
- Configurable HTTP headers by MIME type
- Configurable HTML error documents / CGI executables
- Directory browsing; view content of directories with HTML links
- Execution of CGI programs/scripts
- SUID/SGID for CGI execution
- Chroot for CGI execution; chroot CGI to Virtual Hosts home
- 3 security layers for CGI execution: by URL limit to X-only ie. CGI dir; for RX-URL imply X-only for X-able files; impose X-only by file extension ie. CGI executables wrongly placed and no X flag
- Quotas for CGI execution; number of simultaneous CGI processes, execution priority, max execution time (duration), max CPU time, memory, filesize
- Quotas of network traffic in/out per Virtual Host (I/O speed limit)
- Quotas of connections per Virtual Host
- Quotas of connections per client IP number
- Access restriction by IP address; forbid and allow-only
- Access restriction by valid HTTP referrer
- Configurable HTTP-log format and location for Virtual Hosts
- Configurable singleprocess or multiprocess architecture
- Chroot for Bauk server process
- Full configurability; virtually all Bauk features are configurable by simple configuration script adjustment
- Easy configuration by script language; built-in configuration script interpreter with preprocessor, file-inclusion, block and single-line comments, two data types, variables, arithmetic operations and built-in functions
- Easy administration
- Flexibility
VLAJKOS INVISIBLE LICENSE (VIL):
This sofware is protected by VIL and the license states:
Youre welcome to use this software. Remember the rightful author if youre using any parts/unique components of Bauk software.
Enhancements:
- This release includes various feature enhancements
- improved PHP, Perl, Gawk
- Tcl interpreter connectors
- additions to the documentation.

httping is a "ping"-like tool for HTTP requests. Give it a URL and it will show how long it takes to connect, send a request, and retrieve the reply (only the headers).
httping can be used for monitoring or statistical purposes (measuring latency).
Enhancements:
- A big memory leak in the SSL code was fixed.
- An audible ping mode was added.

HTTP::WebTest::XMLParser is a Perl module to parse webscript in XML representation.

SYNOPSIS

use HTTP::WebTest::XMLParser;
my ($tests, $opts) = HTTP::WebTest::XMLParser->parse($xmldata);

use HTTP::WebTest;
my $wt = new HTTP::WebTest;
$wt->run_tests($tests, $opts);

HTTP::WebTest::XMLParser->as_xml($tests, $opts, { nocode => 1 });

Parses a wtscript file in XML format and converts it to a set of test objects.

XML SYNTAX

The xml format follows wtscript closely, with the following rules:

- the root element is
- global paramters are in a element
- test definitions are in elements
- a list is represented by a element
- a scalar param. is represented by a element
- a code segment is represented by a element
- named parameters are named throug a name attribute

The DTD is available in scripts/webtest.dtd from the distribition. For examples see the test definitions in t/*xml from the distribution.

A conversion script from wtscript to XML is available in scripts/testconversion from the distribution. This script also converts XML definitions from earlier alpha versions of this module.