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.

Send me your comments.

Cameron Kaiser