Table of Contents:

SYNOPSIS
DESCRIPTION
REQUIREMENTS
CONFIGURATION FILE
CONFIGURATION OPTIONS
CALLBACK FUNCTIONS
- More on setting flags
SIGNALS
COPYRIGHT
SUPPORT

[ TOC ]

SYNOPSIS

swish.config: IndexDir ./spider.pl SwishProgParameters spider.config # other swish-e settings

spider.config: @servers = ( { base_url => 'http://myserver.com/', email => 'me@myself.com', # other spider settings described below }, );

Begin indexing:

swish-e -S prog -c swish.config

Note: When running on some versions of Windows (e.g. Win ME and Win 98 SE) you may need to index using the command:

perl spider.pl | swish-e -S prog -c swish.conf -i stdin

This pipes the output of the spider directly into swish.

[ TOC ]

DESCRIPTION

This is a swish-e ``prog'' document source program for spidering web servers. It can be used instead of the http method for spidering with swish.

The spider typically uses a configuration file that lists the URL(s) to spider, and configuration parameters that control the behavior of the spider. In addition, you may define callback perl functions in the configuration file that can dynamically change the behavior of the spider based on URL, HTTP response headers, or the content of the fetched document. These callback functions can also be used to filter or convert documents (e.g. PDF, gzip, MS Word) into a format that swish-e can parse. Some examples are provided.

You define ``servers'' to spider, set a few parameters, create callback routines, and start indexing as the synopsis above shows. The spider requires its own configuration file (unless you want the default values). This is NOT the same configuration file that swish-e uses.

The example configuration file SwishSpiderConfig.pl is included in the prog-bin directory along with this script. Please just use it as an example, as it contains more settings than you probably want to use. Start with a tiny config file and add settings as required by your situation.

The available configuration parameters are discussed below.

If all that sounds confusing, then you can run the spider with default settings. In fact, you can run the spider without using swish just to make sure it works. Just run

./spider.pl default http://someserver.com/sometestdoc.html

And you should see sometestdoc.html dumped to your screen. Get ready to kill the script if the file you request contains links as the output from the fetched pages will be displayed.

./spider.pl default http://someserver.com/sometestdoc.html > output.file

might be more friendly.

If the first parameter passed to the spider is the word ``default'' (as in the preceeding example) then the spider uses the default parameters, and the following parameter(s) are expected to be URL(s) to spider. Otherwise, the first parameter is considered to be the name of the configuration file (as described below). When using -S prog, the swish-e configuration setting SwishProgParameters is used to pass parameters to the program specified with IndexDir or the -i switch.

If you do not specify any parameters the program will look for the file

SwishSpiderConfig.pl

in the current directory.

The spider does require Perl's LWP library and a few other reasonably common modules. Most well maintained systems should have these modules installed. If not, start here:

http://search.cpan.org/search?dist=libwww-perl http://search.cpan.org/search?dist=HTML-Parser

See more below in REQUIREMENTS. It's a good idea to check that you are running a current version of these modules.

[ TOC ]

Robots Exclusion Rules and being nice

By default, this script will not spider files blocked by robots.txt. In addition, The script will check for <meta name=``robots''..> tags, which allows finer control over what files are indexed and/or spidered. See http://www.robotstxt.org/wc/exclusion.html for details.

This spider provides an extension to the <meta> tag exclusion, by adding a NOCONTENTS attribute. This attribute turns on the no_contents setting, which asks swish-e to only index the document's title (or file name if not title is found).

For example:

says to just index the document's title, but don't index its contents, and don't follow any links within the document. Granted, it's unlikely that this feature will ever be used...

If you are indexing your own site, and know what you are doing, you can disable robot exclusion by the ignore_robots_file configuration parameter, described below. This disables both robots.txt and the meta tag parsing. You may disable just the meta tag parsing by using ignore_robots_headers.

This script only spiders one file at a time, so load on the web server is not that great. And with libwww-perl-5.53_91 HTTP/1.1 keep alive requests can reduce the load on the server even more (and potentially reduce spidering time considerably!)

Still, discuss spidering with a site's administrator before beginning. Use the delay_sec to adjust how fast the spider fetches documents. Consider running a second web server with a limited number of children if you really want to fine tune the resources used by spidering.

[ TOC ]

Duplicate Documents

The spider program keeps track of URLs visited, so a document is only indexed one time.

The Digest::MD5 module can be used to create a ``fingerprint'' of every page indexed and this fingerprint is used in a hash to find duplicate pages. For example, MD5 will prevent indexing these as two different documents:

http://localhost/path/to/some/index.html http://localhost/path/to/some/

But note that this may have side effects you don't want. If you want this file indexed under this URL:

http://localhost/important.html

But the spider happens to find the exact content in this file first:

http://localhost/developement/test/todo/maybeimportant.html

Then only that URL will be indexed.

[ TOC ]

Broken relative links

Some times web page authors use too many /../ segments in relative URLs which reference documents above the document root. Some web servers such as Apache will return a 400 Bad Request when requesting a document above the root. Other web servers such as Micorsoft IIS/5.0 will try and ``correct'' these errors. This correction will lead to loops when spidering.

The spider can fix these above-root links by placing the following in your spider config:

remove_leading_dots => 1,

It is not on by default so that the spider can report the broken links (as 400 errors on sane webservers).

[ TOC ]

Compression

If The Perl module Compress::Zlib is installed the spider will send the

Accept-Encoding: gzip

header and uncompress the document if the server returns the header

Content-Encoding: gzip

MD5 checksomes are done on the compressed data.

MD5 may slow down indexing a tiny bit, so test with and without if speed is an issue (which it probably isn't since you are spidering in the first place). This feature will also use more memory.

Note: the ``prog'' document source in swish bypasses many swish-e configuration settings. For example, you cannot use the IndexOnly directive with the ``prog'' document source. This is by design to limit the overhead when using an external program for providing documents to swish; after all, with ``prog'', if you don't want to index a file, then don't give it to swish to index in the first place.

So, for spidering, if you do not wish to index images, for example, you will need to either filter by the URL or by the content-type returned from the web server. See CALLBACK FUNCTIONS below for more information.

[ TOC ]

REQUIREMENTS

Perl 5 (hopefully at least 5.00503) or later.

You must have the LWP Bundle on your computer. Load the LWP::Bundle via the CPAN.pm shell, or download libwww-perl-x.xx from CPAN (or via ActiveState's ppm utility). Also required is the the HTML-Parser-x.xx bundle of modules also from CPAN (and from ActiveState for Windows).

http://search.cpan.org/search?dist=libwww-perl http://search.cpan.org/search?dist=HTML-Parser

You will also need Digest::MD5 if you wish to use the MD5 feature. HTML::Tagset is also required. Other modules may be required (for example, the pod2xml.pm module has its own requirementes -- see perldoc pod2xml for info).

The spider.pl script, like everyone else, expects perl to live in /usr/local/bin. If this is not the case then either add a symlink at /usr/local/bin/perl to point to where perl is installed or modify the shebang (#!) line at the top of the spider.pl program.

Note that the libwww-perl package does not support SSL (Secure Sockets Layer) (https) by default. See README.SSL included in the libwww-perl package for information on installing SSL support.

[ TOC ]

CONFIGURATION FILE

Configuration is not very fancy. The spider.pl program simply does a do "path"; to read in the parameters and create the callback subroutines. The path is the first parameter passed to the spider script, which is set by the Swish-e configuration setting SwishProgParameters.

For example, if in your swish-e configuration file you have

SwishProgParameters /path/to/config.pl IndexDir /home/moseley/swish-e/prog-bin/spider.pl

And then run swish as

swish-e -c swish.config -S prog

swish will run /home/moseley/swish-e/prog-bin/spider.pl and the spider.pl program will receive as its first parameter /path/to/config.pl, and spider.pl will read /path/to/config.pl to get the spider configuration settings. If SwishProgParameters is not set, the program will try to use SwishSpiderConfig.pl by default.

There is a special case of:

SwishProgParameters default http://www.mysite/index.html ...

Where default parameters are used. This will only index documents of type text/html or text/plain, and will skip any file with an extension that matches the pattern:

/\.(?:gif|jpeg|.png)$/i

This can be useful for indexing just your web documnts, but you will probably want finer control over your spidering by using a configuration file.

The configuration file must set a global variable @servers (in package main). Each element in @servers is a reference to a hash. The elements of the has are described next. More than one server hash may be defined -- each server will be spidered in order listed in @servers, although currently a global hash is used to prevent spidering the same URL twice.

Examples:

my %serverA = ( base_url => 'http://swish-e.org/', same_hosts => [ qw/www.swish-e.org/ ], email => 'my@email.address', ); my %serverB = ( ... ... ); @servers = ( \%serverA, \%serverB, );

[ TOC ]

CONFIGURATION OPTIONS

This describes the required and optional keys in the server configuration hash, in random order...

base_url

This required setting is the starting URL for spidering.

Typically, you will just list one URL for the base_url. You may specify more than one URL as a reference to a list

base_url => [qw! http://swish-e.org/ http://othersite.org/other/index.html !],

You may specify a username and password:

base_url => 'http://user:pass@swish-e.org/index.html',

but you may find that to be a security issue. If a URL is protected by Basic Authentication you will be prompted for a username and password. This might be a slighly safer way to go.

The parameter max_wait_time controls how long to wait for user entry before skipping the current URL.

CALLBACK FUNCTIONS

Three callback functions can be defined in your parameter hash. These optional settings are callback subroutines that are called while processing URLs.

A little perl discussion is in order:

In perl, a scalar variable can contain a reference to a subroutine. The config example above shows that the configuration parameters are stored in a perl hash.

my %serverA = ( base_url => 'http://sunsite.berkeley.edu:4444/', same_hosts => [ qw/www.sunsite.berkeley.edu:4444/ ], email => 'my@email.address', link_tags => [qw/ a frame /], );

There's two ways to add a reference to a subroutine to this hash:

sub foo { return 1; }

my %serverA = ( base_url => 'http://sunsite.berkeley.edu:4444/', same_hosts => [ qw/www.sunsite.berkeley.edu:4444/ ], email => 'my@email.address', link_tags => [qw/ a frame /], test_url => \&foo, # a reference to a named subroutine );

Or the subroutine can be coded right in place:

The above example is not very useful as it just creates a user callback function that always returns a true value (the number 1). But, it's just an example.

The function calls are wrapped in an eval, so calling die (or doing something that dies) will just cause that URL to be skipped. If you really want to stop processing you need to set $server->{abort} in your subroutine (or send a kill -HUP to the spider).

The first two parameters passed are a URI object (to have access to the current URL), and a reference to the current server hash. The server hash is just a global hash for holding data, and useful for setting flags as described below.

Other parameters may be also passed in depending the the callback function, as described below. In perl parameters are passed in an array called ``@_''. The first element (first parameter) of that array is $_[0], and the second is $_[1], and so on. Depending on how complicated your function is you may wish to shift your parameters off of the @_ list to make working with them easier. See the examples below.

To make use of these routines you need to understand when they are called, and what changes you can make in your routines. Each routine deals with a given step, and returning false from your routine will stop processing for the current URL.

test_url

test_url allows you to skip processing of urls based on the url before the request to the server is made. This function is called for the base_url links (links you define in the spider configuration file) and for every link extracted from a fetched web page.

This function is a good place to skip links that you are not interested in following. For example, if you know there's no point in requesting images then you can exclude them like:

test_url => sub { my $uri = shift; return 0 if $uri->path =~ /\.(gif|jpeg|png)$/; return 1; },

Or to write it another way:

test_url => sub { $_[0]->path !~ /\.(gif|jpeg|png)$/ },

Another feature would be if you were using a web server where path names are NOT case sensitive (e.g. Windows). You can normalize all links in this situation using something like

test_url => sub { my $uri = shift; return 0 if $uri->path =~ /\.(gif|jpeg|png)$/;

$uri->path( lc $uri->path ); # make all path names lowercase return 1; },

The important thing about test_url (compared to the other callback functions) is that it is called while extracting links, not while actually fetching that page from the web server. Returning false from test_url simple says to not add the URL to the list of links to spider.

You may set a flag in the server hash (second parameter) to tell the spider to abort processing.

test_url => sub { my $server = $_[1]; $server->{abort}++ if $_[0]->path =~ /foo\.html/; return 1; },

You cannot use the server flags:

no_contents no_index no_spider

This is discussed below.

test_response

This function allows you to filter based on the response from the remote server (such as by content-type). This function is called while the web pages is being fetched from the remote server, typically after just enought data has been returned to read the response from the web server.

The spider requests a document in ``chunks'' of 4096 bytes. 4096 is only a suggestion of how many bytes to return in each chunk. The test_response routine is called when the first chunk is received only. This allows ignoring (aborting) reading of a very large file, for example, without having to read the entire file. Although not much use, a reference to this chunk is passed as the forth parameter.

Web servers use a Content-Type: header to define the type of data returned from the server. On a web server you could have a .jpeg file be a web page -- file extensions may not always indicate the type of the file. The third parameter ($_[2]) returned is a reference to a HTTP::Response object:

For example, to only index true HTML (text/html) pages:

test_response => sub { my $content_type = $_[2]->content_type; return $content_type =~ m!text/html!; },

You can also set flags in the server hash (the second parameter) to control indexing:

no_contents -- index only the title (or file name), and not the contents no_index -- do not index this file, but continue to spider if HTML no_spider -- index, but do not spider this file for links to follow abort -- stop spidering any more files

For example, to avoid index the contents of ``private.html'', yet still follow any links in that file:

test_response => sub { my $server = $_[1]; $server->{no_index}++ if $_[0]->path =~ /private\.html$/; return 1; },

Note: Do not modify the URI object in this call back function.

filter_content

This callback function is called right before sending the content to swish. Like the other callback function, returning false will cause the URL to be skipped. Setting the abort server flag and returning false will abort spidering.

You can also set the no_contents flag.

This callback function is passed four parameters. The URI object, server hash, the HTTP::Response object, and a reference to the content.

You can modify the content as needed. For example you might not like upper case:

filter_content => sub { my $content_ref = $_[3];

$$content_ref = lc $$content_ref; return 1; },

I more reasonable example would be converting PDF or MS Word documents for parsing by swish. Examples of this are provided in the prog-bin directory of the swish-e distribution.

You may also modify the URI object to change the path name passed to swish for indexing.

filter_content => sub { my $uri = $_[0]; $uri->host('www.other.host') ; return 1; },

Swish-e's ReplaceRules feature can also be used for modifying the path name indexed.

Here's a bit more advanced example of indexing text/html and PDF files only:

use pdf2xml; # included example pdf converter module $server{filter_content} = sub { my ( $uri, $server, $response, $content_ref ) = @_;

return 1 if $response->content_type eq 'text/html'; return 0 unless $response->content_type eq 'application/pdf';

# for logging counts $server->{counts}{'PDF transformed'}++;

$$content_ref = ${pdf2xml( $content_ref )}; return 1; }

Note: Swish-e not includes a method of filtering based on the SWISH::Filter Perl modules. See the SwishSpiderConfig.pl file for an example how to use SWISH::Filter in a filter_content callback function.

Note that you can create your own counters to display in the summary list when spidering is finished by adding a value to the hash pointed to by $server-{counts}>.

test_url => sub { my $server = $_[1]; $server->{no_index}++ if $_[0]->path =~ /private\.html$/; $server->{counts}{'Private Files'}++; return 1; },

Each callback function must return true to continue processing the URL. Returning false will cause processing of the current URL to be skipped.

[ TOC ]

More on setting flags

Swish (not this spider) has a configuration directive NoContents that will instruct swish to index only the title (or file name), and not the contents. This is often used when indexing binary files such as image files, but can also be used with html files to index only the document titles.

As shown above, you can turn this feature on for specific documents by setting a flag in the server hash passed into the test_response or filter_content subroutines. For example, in your configuration file you might have the test_response callback set as:

test_response => sub { my ( $uri, $server, $response ) = @_; # tell swish not to index the contents if this is of type image $server->{no_contents} = $response->content_type =~ m[^image/]; return 1; # ok to index and spider this document }

The entire contents of the resource is still read from the web server, and passed on to swish, but swish will also be passed a No-Contents header which tells swish to enable the NoContents feature for this document only.

Note: Swish will index the path name only when NoContents is set, unless the document's type (as set by the swish configuration settings IndexContents or DefaultContents) is HTML and a title is found in the html document.

Note: In most cases you probably would not want to send a large binary file to swish, just to be ignored. Therefore, it would be smart to use a filter_content callback routine to replace the contents with single character (you cannot use the empty string at this time).

A similar flag may be set to prevent indexing a document at all, but still allow spidering. In general, if you want completely skip spidering a file you return false from one of the callback routines (test_url, test_response, or filter_content). Returning false from any of those three callbacks will stop processing of that file, and the file will not be spidered.

But there may be some cases where you still want to spider (extract links) yet, not index the file. An example might be where you wish to index only PDF files, but you still need to spider all HTML files to find the links to the PDF files.

$server{test_response} = sub { my ( $uri, $server, $response ) = @_; $server->{no_index} = $response->content_type ne 'application/pdf'; return 1; # ok to spider, but don't index }

So, the difference between no_contents and no_index is that no_contents will still index the file name, just not the contents. no_index will still spider the file (if it's text/html) but the file will not be processed by swish at all.

Note: If no_index is set in a test_response callback function then the document will not be filtered. That is, your filter_content callback function will not be called.

The no_spider flag can be set to avoid spiderering an HTML file. The file will still be indexed unless no_index is also set. But if you do not want to index and spider, then simply return false from one of the three callback funtions.

[ TOC ]

SIGNALS

Sending a SIGHUP to the running spider will cause it to stop spidering. This is a good way to abort spidering, but let swish index the documents retrieved so far.

[ TOC ]

COPYRIGHT

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

[ TOC ]

SUPPORT

Send all questions to the The SWISH-E discussion list.

See http://sunsite.berkeley.edu/SWISH-E. [ TOC ]

spider.pl - Example Perl program to spider web servers