Copperweb

or, in which Cameron Kaiser wastes a lot of time on the wildly
impractical

or, a possible way in which your classic System 7 or A/UX Macintosh can
shore up its sucky browser support

This is just a placeholder page for one of my toy projects, Copperweb (an
elision of "Co-Processor for the Web"). Enjoy it. Last modified 9 May 2011.

The basic notion

68K Macs don't have good browser choices, and few people are known to be
working on any browser support for them at
all. (For PowerPC Mac OS 8.6 and up, of course, you do have a better
choice -- see Classilla, also
maintained by yours truly.) Most people are doing their best to plug along
with Netscape or IE, both of which have serious drawbacks on System 7. iCab 2.x
is probably the most powerful, but has high system requirements and a
commensurate pricetag, and itself has fairly bad support by modern standards.

Part of this problem is sites presenting data the browser can't understand;
people have long gritted their teeth at Netscape popping up a dialogue box
for every single ticky error. Part of it is the browser simply lacking core
functionality. Unfortunately, there have been no maintained compilers for the
classic Mac OS for years and even the venerable CodeWarrior can't compile a
lot of new ANSI code. So if building a new browser is difficult, change the
input the browser is getting -- in other words, build a proxy and feed it data
it can actually understand.

Naturally, anyone could go throw such a proxy
on their local server, and there are such tools that could be modified for
this purpose, but it defeats the purpose of using a classic Mac for
web browsing because the server is doing the work (and would probably be
considered cheating by the annual Retro Challenge judges). That brings us to
Copperweb, an implementation of such a proxy that you can run locally on
the Mac itself.

Copperweb is a work in progress and essentially a toy project. You should
not expect much out of it and I would be impressed if you tried to use it
on a practical basis. But I do accept patches!

Copperweb's design

Copperweb is a single-threaded, single-process userland
HTTP proxy written in Perl 4.
Perl 4 was chosen because MacPerl 4.1.8 can run on very minimal installs of
System 7 (it was tested on a IIci with System 7.1) and many A/UX builds are
capable of compiling or may already have Perl 4.036. Similarly, being
text, you can tweak it with your favourite text editor. It may or may not
work correctly with Perl 5, although it seems to be okay with Mac OS X
10.4.

To use it, disable your browser's multiple connection support (as it will
probably make the browser act funny) and point your browser's proxy settings
to your Mac's IP, port 8080. You might need to restart your browser, and
some browsers may not work right with Copperweb; see below. Sites you know
don't need proxy processing can be placed into your browser's "don't proxy"
list, if it supports that.

Copperweb will then take requests from your browser and fetch them, rewriting
the requests as needed on the fly. Anything that is not HTML will simply be
spewed back. If the document is HTML, however, then it will be checked
and stripped of most JavaScript, CSS and iframes. When done, it will
wait for another request.

Copperweb is slow

Because it is single-tasking, it cannot fetch
multiple resources at once and images must load one by one. Similarly, the
overhead of preprocessing the page can be a lot for low-end systems; even my
50MHz '030 IIci with 72MB of RAM generally required two to three times more
processing with Copperweb than without it. On top of all that, the cooperative
multitasking nature of the classic MacOS can conspire to leave both the
browser and proxy starved for data -- while a deadlock situation is unlikely,
it can further make throughput spotty.

That said, there were some sites
that the IIci could never have accessed before that Copperweb enabled.
There is always a price to be paid.

Specific version notes

Copperweb on System 7 with MacPerl

Most people will want this version. If you have A/UX, however, you should
use the A/UX specific version below as it overcomes a lot of the drawbacks
of this MacOS specific version. This version was tested on a Mac IIci with
System 7.1.

Copperweb for MacOS only works well with a subset of browsers. Internet
Explorer 2.1 works okay with it. Netscape 2.02 will talk to it, but throws
frequent socket errors (this appears to be a manifestation of the infamous
error
-3155 which still plagues WaMCom and is finally being fixed in Classilla).
NCSA Mosaic seems not to like it at all. You may need to experiment to see
what will tolerate it, as the socket code in MacPerl seems to have some
glitches. The A/UX version doesn't have this problem, by the way.

To begin, preconfigure your browser to point to your Mac's IP and port 8080
as its HTTP proxy, and quit the browser.
Make sure you have MacPerl installed (here is a naked binary with just the MacPerl 4.1.8 executable),
then download Copperweb for Mac (MacBinary)
and decode it. Double-click the script and press Cmd-Shift-R to start it. A
new window will appear. Press RETURN to start the proxy and wait until the
camel spinning cursor appears, then start your browser. You can watch
network and proxy activity in the MacPerl window to reassure you during the
slow moments that your Mac has not frozen.

Because the MacOS version cannot preemptively multitask, the browser can
steal CPU cycles from it trying to process things faster (and in this case
starving itself for data by idling Copperweb, making it slower). Also,
because MacPerl doesn't and will never support multiple processes,
and MacPerl 4.1.8 has specific bugs in its implementation of select(),
it cannot handle multiple requests at once. Occasionally these socket
irregularities will conspire to unsettle the browser and even uncover a bug.
Well, it's not that the dog walked well, as they say.

Also, due to the incomplete socket implementation available and MacPerl
4.1.8 lacking alarm(), it is possible to hang sockets waiting
for hosts that will never answer. Fortunately this shouldn't hang the OS;
just switch to MacPerl and press Cmd-Period once. This will
interrupt the current connection call and cause it to return an error
message to the browser.

Finally, never quit MacPerl with Copperweb running. Stop the proxy
first with Cmd-Period, and then it is safe to quit MacPerl. If you don't,
handlers don't get cleaned up and can cause the Mac to freeze.

Copperweb on A/UX

If you have A/UX, you should use this version as it is much more functional
and somewhat faster. This version was tested on the same Mac IIci, booting
A/UX 3.1.1 with Perl 4.036 built from Jagubox.
I have not tried it with A/UX 2. Good luck, let me know if it works. It may
also work with other Unixy things; I did some cursory testing with Classic
browsers in Mac OS X 10.4 and it seemed to be reasonably happy with the
provided Perl 5.8.6.

Copperweb on A/UX is started from the CommandShell. Download it and use
fcnvt if needed to turn it into a regular Unix text file.
Then, in a CommandShell window,
run it under perl (such as
/usr/local/bin/perl copperweb.aux.pl). It will start immediately,
unlike the MacOS version, and flag ready when it has
bound the port and is ready to serve. If you get bind: errors,
quit your browser and the CommandShell, cycle to the Finder, and restart
CommandShell.

The A/UX version works happily with most browsers (note: this is only
true for A/UX! -- it is
not the case for running browsers in Classic with 10.4, as Classic
suffers from the same drawbacks as the MacOS version despite the proxy
running on a native Perl) and was tested with Netscape 2.02 and IE 2.1. It
is also about 25% faster than the MacOS version, largely due to the fact that
it can preemptively multitask and thus the browser can't starve it
of CPU cycles, and it is able to timeout sockets and save itself if a host
is not answering.

Things to do

Improve parsing speed. Copperweb tries to cheat and snoop on the
output stream to make sure it doesn't need to rewrite anything. However,
it is probably a lot to ask of a little 68K to proxy its own data, rewrite
it on the fly and parse and display it. When rewriting is required,
throughput usually drops to less than 0.5k/sec, even on fast '030s. There
is a lot of optimization in the current version to improve this. More is
likely possible.

Allow multiprocessing on A/UX. This will require some care not to totally
gut the structure of the proxy since the same base is used to generate both
versions. fork() is probably the best approach.

Custom user agents to mimic cell phones. This would be very handy
for mobile sites which are a good fit for older computers.

Perl 5 testing so that people with Perl 5 can at least take advantage
of it. You can do this and help me out, btw. :)

Source

You can get the "source archive" (just a Makefile and the base
code) as a ZIP archive. Just put them somewhere
and type make to build the classic Mac, A/UX and source archive
forms. It needs Mac OS X 10.4
and the Developer tools to build; it uses
/Developer/Tools/SetFile and the macbinconv package to
construct the Classic MacOS archive. If you don't have this or don't care,
you can just use make aux to build the A/UX target.