Web Server Like It’s 1998 With This Restored Internet Appliance

Hackaday readers fit into two broad categories: those who experienced the wild and woolly early days of the Internet, and those who are jealous that they missed it. And it’s safe to say that both groups will get something out of this aggressively Web 1.0 retro experience, courtesy of a server that was actually part of it.

This comes to us via The Serial Port, a virtual museum dedicated to 90s technology, where curators [Mark] and [Ben] managed to find a pair of Cobalt RaQ 3 servers from the late 1990s. The RaQ was the first true “Internet appliance,” designed to be as simple as possible to set up and operate. If you wanted to get your small business online, machines like these were just the ticket. They were designed to be as plug-and-play as possible, and they did a pretty good job of it, at least for the time.

The machines that showed up were quite the worse for the wear, which is understandable given the decades since they were last relevant, but that just makes it all the more fun to get them going again. One didn’t even come close to booting, but the other showed more promise.

The video below is the first of a three-part series, and has a nice introduction to the RaQ and its important place in the early Internet, as well as a peek inside the two machines. That revealed some leaky caps that needed replacement in Part 2; after that minor surgery and a little persuasion, the 300-MHz screamer was ready for a test run. It worked, and The Serial Port put it right to work in Part 3 hosting a gloriously retro home page. Hit the link at the top of the article and enjoy the 90s all over again — the visitor counter, the mixed fonts, the “Under Construction” animated GIF, and the reminder to bookmark this page in your browser, which was probably Netscape Navigator. We love the guestbook, too. But — no marquee?

Nice job, [Mark] and [Ben], and kudos for keeping this little slice of computing history alive.

Continue reading “Web Server Like It’s 1998 With This Restored Internet Appliance”

Pi Microcontroller Still Runs A Webserver

At first glance, the Raspberry Pi Pico might seem like a bit of a black sheep when compared to the other offerings from the Raspberry Pi Foundation. While most of the rest of their lineup can run Linux environments with full desktops, the Pico is largely limited to microcontroller duties in exchange for much smaller price tags and footprints. But that doesn’t mean it can’t be coerced into doing some of the things we might want a mainline Pi to do, like run a web server.

The project can run a static web page simply by providing the Pico with the project code available on the GitHub page and the HTML that you’d like the Pico to serve. It can be more than a static web page though, as it is also capable of running Python commands through the web interface as well. The server can pass commands from the web server and back as well, allowing for control of various projects though a browser interface. In theory this could be much simpler than building a physical user interface for a project instead by offloading all of this control onto the web server instead.

The project not only supports the RP2040-based Raspberry Pi Pico but can also be implemented on other WiFi-enabled microcontroller boards like the ESP8266 and ESP32. Having something like this on hand could greatly streamline smaller projects without having to reach for a more powerful (and more expensive) single-board computer like a Pi 3 or 4. We’ve seen some other builds on these boards capable of not only running HTML and CSS renderers, but supporting some image formats as well.

Continue reading “Pi Microcontroller Still Runs A Webserver”

Squish That Stack With Rampart

[P B Richards] and [Aaron Flin] were bemoaning the resource hunger of modern JavaScript environments and planned to produce a system that was much stingier with memory and CPU, that would fit better on lower-end platforms. Think Nginx, NodeJS, and your flavour of database and how much resource that all needs to run properly. Now try wedge that lot onto a Raspberry Pi Zero. Well, they did, creating Rampart: a JavaScript-based complete stack development environment.

The usual web applications have lots of tricks to optimise for speed, but according to the developers, Rampart is still pretty fast. Its reason for existence is purely about resource usage, and looking at a screen grab, the Rampart HTTP server weighs in at less than 10 MB of RAM. It appears to support a decent slew of technologies, such as HTTPS, WebSockets, SQL search, REDIS, as well as various utility and OS functions, so shouldn’t be so lightweight as to make developing non-trivial applications too much work. One interesting point they make is that in making Rampart so frugal when deployed onto modern server farms it could be rather efficient. Anyway, it may be worth a look if you have a reasonable application to wedge onto a small platform.

We’ve seen many JavaScript runtimes over the years, like this recent effort, but there’s always room for one more.

ESP8266 Web Server Saves 60% Power With A 1 Ms Delay

Arduino has a library for quickly and easily setting up a simple web server on an ESP8622-based board, and [Tomaž] found that power consumption on an ESP-01 can be reduced a considerable amount by simply inserting a 1 ms delay in the right place. The reason this works isn’t because of some strange bug or oddball feature — it’s really just a side effect of how the hardware operates under the hood.

[Tomaž] uses the “hello world” example from ESP8266WebServer to explain. In it, the main loop essentially consists of calling server.handleClient() forever. That process checks for incoming HTTP connections, handles them, sends responses, exits — and then does it all over again. A simple web server like this one spends most of its time waiting.

A far more efficient way to handle things would be to launch server.handleClient() only when an incoming network connection calls for it, and put the hardware to sleep whenever that is not happening. However, that level of control just isn’t possible in the context of the Arduino’s ESP8266WebServer library.

So what’s to be done? The next best thing turns out to be a simple delay(1) statement right after each server.handleClient() call in the main loop.

Why does this work? Adding delay(1) actually causes the CPU to spend the vast majority of its time in that one millisecond loop. And counting microseconds turns out to be a far less demanding task, power-wise, than checking for incoming network requests about a hundred thousand times per second. In [Tomaž]’s tests, that one millisecond delay reduced idle power consumption at 3.3 V from roughly 230 mW to around 70 mW — about 60% — while only delaying the web server’s response times by 6-8 milliseconds.

For simple web server applications, this is is for sure a good trick to keep in mind. There are also much more advanced techniques for saving power on ESP8266-based boards; from boards that barely sip a single microamp while sleeping, to coin-cell powered boards that go so far as to modify the TCP/IP stack to help squeeze every bit of power savings possible.

HP-200LX Runs Website Like It’s The 90s

The HP-200LX palmtop was a fascinating machine for its time, and [Terrence Vergauwen] proves that its time is not yet over, given that one is responsible for serving up the website for Palmtop Tube, a website and YouTube channel dedicated to vintage palmtops.

All by itself a HP-200LX doesn’t have quite what it takes to act as a modern web server, but it doesn’t take much to provide the missing pieces. A PCMCIA network adapter provides an Ethernet connection, and a NAS contains the website content while networking and web server software run locally. Steady power comes from a wall adapter, but two rechargeable AA cells in the 200LX itself act as a mini-UPS, providing backup power in case of outages.

The HP-200LX was a breakthrough product that came just at the right time, preceding other true palm top computers like the IBM PC 110. In the early 90s, it was unimaginable that one could have a fully functional MS-DOS based machine in one’s pocket, let alone one that could last weeks on a couple of AA cells. It didn’t have some proprietary OS and weird ports, and that kind of functionality is part of why, roughly 30 years later, one is able to competently serve up web traffic.

A video overview of the machine and how it all works is in the video embedded below. And if you’re more interested in what an HP-200LX looks like on the inside? This video is all about taking apart and repairing a 200LX.

Continue reading “HP-200LX Runs Website Like It’s The 90s”

PHONK – A Hacker’s Fun Shortcut To Android Programming

As the common myth goes, the average human utilizes only about 10% of the true potential their smartphone is capable of. Especially when it comes to electronics projects, it seems that we often overlook how we can integrate and take advantage of their functionality here. Maybe that’s not a big surprise though — while it isn’t rocket science, getting into mobile development certainly has its hurdles and requires a bit of commitment. [Victor Diaz] figured there had to be a better way, so he went on and created PHONK, the self-contained creative scripting toolbox for Android.

PHONK is installed like any other app, and allows rapid prototyping on your Android device via JavaScript by abstracting away and simplifying the heavily boilerplated, native Java parts. So instead of setting up an app from scratch with all the resources defining, UI design, activity and application lifecycle management — not to mention the Android development environment itself — PHONK takes care of all that behind the curtain and significantly reduces the amount of code required to achieve the task you’re actually interested in. In case you’re worrying now that you have to actually program on your phone, well, you can, which can definitely come in handy, but you don’t have to.

Once the app is opened, a web server is started, and connecting to it from any modern browser within the same WiFi network presents you the PHONK development environment with everything you need: editor, file browser, console, and API documentation. You can write your code in the browser, and pressing the run button will execute it straight on the device then. As everything is self-contained within the app itself, no additional software is required, and you can start right away by exploring the set of provided examples that showcase everything supported so far: sensor interaction, BLE server and client, communication protocols like MQTT or WebSockets, OpenStreetMap maps, and even integration with Pure Data and Processing. Attach a USB OTG cable and you can program your Arduino, have serial communication, or interface a IOIO board. You can even connect a MIDI controller.

This is really impressive work done by [Victor], and a lot of attention to detail went into the development. If you have an old Android phone collecting dust somewhere, this would be a great opportunity to revive it and build something with it. And as [Victor] writes on the project’s GitHub page, he’s always curious what people will come up with. If you’re thinking about building a mobile sensor lab, or want to learn more about the sensors inside your phone, have a look at the 36C3 talk about phyphox.

Secret Messages Could Be Hiding In Your Server Logs

[Ryan Flowers] writes in with a clever little hack that can allow you to hide data where nobody is going to go looking for it. By exploiting the fact that a web server will generally log all HTTP requests whether or not it’s valid, he shows how you can covertly send a message by asking the server for a carefully crafted fictitious URL.

We aren’t talking about requesting “yousuck.txt” from the server that hosts your least favorite website, either. As [Ryan] demonstrates, you can compress a text file, encode it with uuencode, and then send it line by line to the destination server with curl. He shows how the process, which he calls “CurlyTP” can be done manually on the command line, but it would be a simple matter of wrapping it up in a Bash script.

To get the message back, you just do the opposite. Use grep to find the lines in the log file that contain the encoded data, and then put them through uudecode to get the original text back. Finding the appropriate lines in the log file is made easier by prepending a prearranged keyword to the beginning of the URL requests. The keyword can be changed for each message to make things easier to keep track of.

If you’re still wondering why anyone would go through the trouble to do this, [Ryan] provides an excellent example: a covert “dead drop” where people could leave messages they’d rather not send through the usual channels. As long as the sender used a service to mask their true IP address, they could anonymously deliver messages onto the server without having to use any special software or protocol they might not have access to. Even the most restrictive firewalls and security measures aren’t likely to be scanning URLs for compressed text files.

We’ve seen web-based dead drops done with Python in the past, and even purpose built “PirateBoxes” that allow people to covertly exchange files, but we like how this method doesn’t require any special configuration on the server side. You should check your server logs, somebody might be trying to tell you something.