Web server for 211BSD

[oscarv]

Hi,

I thought this was well worth sharing: Aaron Jackson wrote a small, simple yet effective web server for 211 BSD: https://github.com/AaronJackson/2.11BSDhttpd

For me, it was interesting because it's small enough to demystify http stuff of which I know little. 1 page of C code is all!

In addition to the recipe on his github page, I found this is what I had to add to /etc/inetd.conf:

http    stream  tcp     nowait  nobody  /usr/libexec/httpd      httpd

Insert this to /etc/services :

http          80/tcp

 

Copy a simple index.html file into /var/www; use chmod on it if you get ‘file not found’ messages from your web browser.

Kind regards,

Oscar.

[Craig Ruff]

It has all kinds of security problems, so don't go exposing it to the world.

[Aaron Jackson]

Indeed, this certainly will have many security issues. It was just a small project for an afternoon.

I suppose though, if/when it is compromised, it probably wouldn't matter (to most people) too much

Thanks for sharing, Oscar.

Aaron

[Oscar Vermeulen]

Aaron,

On Tue, 14 May 2019 at 15:41, Aaron Jackson <aa...@aaronsplace.co.uk> wrote:

Indeed, this certainly will have many security issues. It was just a small project for an afternoon.

I suppose though, if/when it is compromised, it probably wouldn't matter (to most people) too much

I'd be delighted to find someone had hacked into my PDP-11 web server, and beg to post a write-up on it here. Who knows!

Kind regards,

Oscar.

[Paul Birkel]

No, no, no.  They’re supposed to send their findings to WikiLeaks …

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAJAwMc2wKG6umBMwgWJf-NgUVDdA6DP_jhev7rcdafRu69XhbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Morton]

> On 14 May, 2019, at 4:41 pm, Aaron Jackson <aa...@aaronsplace.co.uk> wrote:
>
> Indeed, this certainly will have many security issues. It was just a small project for an afternoon.

I took a quick look at it, and found that the most common vulnerability classes had been addressed in the code to a reasonable extent. I did notice this bug however:

/* Extract file type and output content-type header */
ext = rindex(path, '.');
if (!strcmp(ext, ".html"))
printf("Content-Type: text/html\r\n");
else if (!strcmp(ext, ".jpg"))
printf("Content-Type: image/jpeg\r\n");
else
printf("Content-Type: text/plain\r\n");

If rindex() doesn't locate the character being searched for, it returns NULL, which will result in a segfault when strcmp() is then called (assuming zero page is unmapped as in modern UNIXes). You should avoid this by checking the value of ext and either reinitialising it to point to a null terminator, or incorporating such a check into every branch of the conditional:

ext = rindex(path, '.');
+ if (!ext) ext = rindex(path, 0);
if (!strcmp(ext, ".html"))

- Jonathan Morton

[Aaron Jackson]

Thanks Jonathan, that's good to hear.

I will add the fix you suggest.

Aaron

[Johnny Billquist]

On 2BSD it will not give a segfault, as address 0 is available. Not
enough virtual memory space around to make it reasonable to waste some
that way. One page is 8K... :-)
(If the system were to be very tricky, it could just unmap the first 64
bytes, but that would require some clever programming in the kernel.)

> ext = rindex(path, '.');
> + if (!ext) ext = rindex(path, 0);
> if (!strcmp(ext, ".html"))

Why not just ext = ""; in the case ext is NULL? No reason to make it
complicated like that. :-)

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Craig Ruff]

> On May 14, 2019, at 9:06 AM, Jonathan Morton <chrom...@gmail.com> wrote:
>>
> I took a quick look at it, and found that the most common vulnerability classes had been addressed in the code to a reasonable extent. I did notice this bug however:

Practicing good cyber security is a never ending task, and some more comments may be instructive. Looking at the file on GitHub, I see these additional issues beyond the previous comments about rindex:

While line 28 properly prevents a stack overrun due to unbounded input, it fails to detect a truncated HTTP request which may result in returning a reply with a page that was not intended. As a secondary error, the fgets will continue where it left off, resulting in attempting to process the remainder of the truncated request as an new request. Note that fgets does not handle NUL characters specially, so even if the buffer would not have been overflowed, you may see an effectively truncated request due to the use of C-strings.

Line 35 almost certain stack overrun of the path variable by sscanf not having the length of the destination buffer. If the compiler reorders the local variables on the stack, this may result in arbitrary code execution due to a hand crafted buffer contents.

Line 39 will erroneously detect double dots present in the path name that may not be used to indicate the parent directory when adjacent to slash characters.

Line 43 may wrongly decide a file pathname is a directory, or fail to detect a path is a directory.

Line 44 could overrun the path variable when the concatenation is made.

Line 47 should check the return value from stat. The contents of the st structure should be used to make the determination about if the path exists and what type of inode it represents. It would probably be better to open the file first then use fstat on the descriptor to prevent time of check/time of use issues.

[John Kennedy]

No good deed goes unpunished :)

[Jonathan Morton]

> On 15 May, 2019, at 2:39 am, Craig Ruff <cr...@ruffspot.net> wrote:
>
> Practicing good cyber security is a never ending task, and some more comments may be instructive. Looking at the file on GitHub, I see these additional issues beyond the previous comments about rindex:

Well, I did say I'd only taken a *quick* look.

Ultimately, what we learn from this is that C has poor support for string processing, memory management, and secure applications in general, being essentially a "portable assembly language". None of which should be much of a surprise.

- Jonathan Morton

[Antoni Villalonga]

Hi,

On Tue, May 14, 2019 at 06:40:39AM -0600, Craig Ruff wrote:
> It has all kinds of security problems, so don't go exposing it to the world.

Probably no one serve or store secrets on a pdp11 emulator. So it seems a new
toy for our ancient systems.

I agree security it's still important.
For instance, a combination of webserver and Simh bugs may allow unexpected
grave problems (accessing to host machine, internal network, etc).

--
Antoni Villalonga
http://friki.cat/

[leosam]

Hi all, 

I've taken the guts to install it and expose it to the world. I've put the server on a different port other than 80, and I'm running some tests to see how it fares. As of now I must say I'm impressed by the speed! I was expecting something *much* slower.

Thank you Aaron!

A general question: what do we need to do to add CGI-BIN support? Seeing the security fears that have been expressed here, would it be wise to do so?

Best regards,

Leo

[Aaron Jackson]

Glad you are having some fun with it.

I thought about adding some kind of cgi support. I don't think it should
be too difficult either. Feel free to add it! As for the question of
whether it is wise... probably not. :)

Aaron

[Jason Vanick]

It would certainly be interesting to expose a 211bsd instance to the internet as a honeypot.

just make a duplicate of your sdcard... and set it out there for the world.... don't ever return it to your internal network and you should be ok.... even more interesting would be to see:

a) if it got hacked

b) diff the filesystem to a backup (offline obviously) and see what was changed

c) what they did to it.

heck, you could use the 'idle' lights on the console to determine if/when it gets hacked as I'm sure it wouldn't be too idle after something happened.

-J

[Aaron Jackson]

I think a significant amount (perhaps the majority) of malicious
internet activity is automatic and scripted (e.g. constant SSH login
attempts if you don't block them in some way, or trying random requests
on web servers to see how they respond to known bugs).

These scripts are going to be completely unaware of this web server. It
doesn't identify itself and will probably not respond in the same way as
a well known web server might to a particular malicious request. Even
so, in the unlikely event it was cracked into by such a script, maybe
they gain access to a shell. Ok, so, they try wget to download a copy of
their botnet onto the "PDP-11" (probably compiled for x86). wget not
found, at which point they probably give up and move onto a more useful
target with more bandwidth and a faster CPU.

A targeted attack from someone experienced is quite different, but
still, I'm not entirely sure much harm could be caused from the safety
of simh jail (has anyone actually broken out of simh?).

If you are brave and want to expose it publicly (like I have on my
actual PDP-11 for quite a while, and now also on the PiDP-11), don't
blame me if it goes wrong. The license protects me from any liability ;)

Aaron

--
Aaron Jackson - M6PIU
Researcher at University of Nottingham
http://aaronsplace.co.uk/

[Mel Byrne]

Hi Aaron and all,

I built my PiDP-11 a couple of weeks ago and spent a very enjoyable evening last week googling and hacking together my first ever webpage. I know. At my age.

I haven't been brave enough to put it on port 80 - although after Aaron's post that might change - you might like to try flash.brodir.net on port 3236...

If flash.brodir.net is up, it will serve out a photo of itself along with some info and links to more info.

I put the brief info & links in because almost everyone I invited to view said "what is that??" - even the geeks.

Anyway, this post is mainly to say thanks to Aaron for 2.11BSD httpd...using it and PiDP-11 to get on t'internet is great fun.

- Mel

[Aaron Jackson]

Haha looks great!

Mine is emubert.rhwyd.co.uk, with a very low res animated gif ;)

Aaron

Mel Byrne writes:

> Hi Aaron and all,
>
> I built my PiDP-11 a couple of weeks ago and spent a very enjoyable

> evenings last week googling and hacking together my first ever webpage. I

[Randy E (OoMOR)]

Both of these sites are up and running as expected. (But Catbert is taking a nap...)

[Neil Breeden]

I've got the little webserver up and running on my PiDP11 at http://www.shadowtron.com:81/ - at the moment it's live on the internet.

Yes, I know, it's not safe but such is life.

Enjoy!

-neil

[John Kennedy]

Neat! I wonder if I can can get my Altair to run a DOS attack ;-)

[ShadowTron Blog]

That sounds like a fun project. Looking forward to seeing it crash. :)

[Neil Breeden]

Last night I added some basic logging to the little webserver. Overnight the site was hit a few times with some interesting cgi request entries in the log:

requestedFile: /var/www///index.html  Tue Jun 18 22:05:18 2019
fileSent     : /var/www///index.html  Tue Jun 18 22:05:18 2019
fileNotFound : /var/www//%5ccgi-bin/get_status.cgi  Wed Jun 19 00:17:41 2019
fileNotFound : /var/www//%5ccgi-bin/login.cgi  Wed Jun 19 00:17:42 2019
requestedFile: /var/www///index.html  Wed Jun 19 01:22:11 2019
fileSent     : /var/www///index.html  Wed Jun 19 01:22:11 2019
requestedFile: /var/www///index.html  Wed Jun 19 03:52:43 2019
fileSent     : /var/www///index.html  Wed Jun 19 03:52:43 2019
requestedFile: /var/www///index.html  Wed Jun 19 05:20:18 2019
fileSent     : /var/www///index.html  Wed Jun 19 05:20:18 2019
requestedFile: /var/www///index.html  Wed Jun 19 07:01:17 2019
fileSent     : /var/www///index.html  Wed Jun 19 07:01:17 2019
requestedFile: /var/www///index.html  Wed Jun 19 09:24:52 2019
fileSent     : /var/www///index.html  Wed Jun 19 09:24:52 2019
requestedFile: /var/www///index.html  Wed Jun 19 11:27:26 2019
fileSent     : /var/www///index.html  Wed Jun 19 11:27:26 2019

It's pretty cool seeing the site hit and someone fishing for cgi scripts.

-Neil

[leosam]

Hi Neil,

Can you share the way you added log support to Aaron's web server? I've been trying to to exactly this...

Thanks

Leo

[Johnny Billquist]

If you keep that running for a while you will get a fairly interesting
list of the most common security holes around.

I've had a web server running on a public RSX system for a few years,
and the logs of failed requests is a very interesting read.

Johnny

On 2019-06-19 22:24, Neil Breeden wrote:
> Last night I added some basic logging to the little webserver. Overnight
> the site was hit a few times with some interesting cgi request entries
> in the log:
>
> requestedFile: /var/www///index.html  Tue Jun 18 22:05:18 2019
> fileSent     : /var/www///index.html  Tue Jun 18 22:05:18 2019

> *fileNotFound : /var/www//%5ccgi-bin/get_status.cgi  Wed Jun 19 00:17:41
> 2019
> fileNotFound : /var/www//%5ccgi-bin/login.cgi  Wed Jun 19 00:17:42 2019*

> requestedFile: /var/www///index.html  Wed Jun 19 01:22:11 2019
> fileSent     : /var/www///index.html  Wed Jun 19 01:22:11 2019
> requestedFile: /var/www///index.html  Wed Jun 19 03:52:43 2019
> fileSent     : /var/www///index.html  Wed Jun 19 03:52:43 2019
> requestedFile: /var/www///index.html  Wed Jun 19 05:20:18 2019
> fileSent     : /var/www///index.html  Wed Jun 19 05:20:18 2019
> requestedFile: /var/www///index.html  Wed Jun 19 07:01:17 2019
> fileSent     : /var/www///index.html  Wed Jun 19 07:01:17 2019
> requestedFile: /var/www///index.html  Wed Jun 19 09:24:52 2019
> fileSent     : /var/www///index.html  Wed Jun 19 09:24:52 2019
> requestedFile: /var/www///index.html  Wed Jun 19 11:27:26 2019
> fileSent     : /var/www///index.html  Wed Jun 19 11:27:26 2019
>
> It's pretty cool seeing the site hit and someone fishing for cgi scripts.
>
> -Neil
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/dbd261de-81eb-4926-9d2a-be77a2c38b3e%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/dbd261de-81eb-4926-9d2a-be77a2c38b3e%40googlegroups.com?utm_medium=email&utm_source=footer>.

[ShadowTron Blog]

You can get my current source for the httpd webserver from the website itself. The 2nd to the last link on the page will open a tab with the current source. There are notes at the top about the steps I had to take to get it working and to get the logging actually writing to the log file.

http://shadowtron.com:81

The last link on the page will dump the current log file. You can hit the site, request the log dump and see part of your traffic in the dump. :)

Most likely the cgi calls and ico calls I'm seeing are based on scripts probing my IP and not actual hands on hacking activity itself. Still I've been adding little easter eggs to the site should a human actually try the URLs.

http://shadowtron.com:81/cgi_bin/login.cgi
http://shadowtron.com:81/cgi_bin/get_status.cgi

http://shadowtron.com:81/favicon.ico                              This one might be a probe to see if the webserver is IIS. Anyhows, IIS's favicon.ico waits behind this URL.

-Neil

[Digby R.S. Tarvin]

The favicon.ico is just the icon which is displayed in your browser tab. I think it originated with Microsoft, but is not indicative of a Microsoft system. My BSD/OS system has had the attached little BSD dragon for as long as I can remember, and would probably be appropriate on a BSD211 server.

It should be fairly easy to add support for it to the httpd server.

When I connect using chrome it sees a request for 'favicon-32x32.png' and if that fails 'favicon-16x16.png".  So adding a link to the favicon.ico with the latter name was enough to make it work on on the 211 server..

The apache server must be doing something clever, because my BSD/OS system only has the favicon.ico file, and the browser finds it and displays it.

You can see what it looks like if you open my old web page at:

http://skaro.afraid.org:4280

Or here is a screen capture of Chrome with the BSD211 page open showing how the icons are used:

Regards,

DigbyT

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/aa4e1087-3e94-4760-b3a2-85786dc50de1%40googlegroups.com.

[sunnyboy010101]

Neil,

This is just brilliant. I spent the last hour compiling and installing the little server on my PiDP11 / BSD211 machine. It was only an hour because I (of course) had to create a purpose-built set of web files to serve. :-)

Not public just yet - I'm deciding on a port (all the usual suspects are in use here) and then I'll put the port forward in my firewall and see what happens. Of course, using non-standard ports tends to reduce the amount of silly traffic to a trickle. (I have one tomcat application running port 443 and it gets all the usual suspects while another on a different port hasn't really seen any activity except me since I made the switch). Of course the main web server gets a logful every day from the bots.

[sunnyboy010101]

I had to change the default router on my BSD 2.11 machine, but after that I was able to connect to it from the big wide world. As I mentioned just above, I had to add a new rule to my firewall to forward the chosen port to my BSD 2.11 machine, but it all works. Except...

The new firefox simply refuses to connect anything to http. It instantly converts http to https and then refuses to connect. That is, I type in http://<server>:<port> to Firefox and it instantly becomes https://<server>:<port> which (of course) won't connect. Even if I correct it to http, it just changes it back. Dumb.

On the other hand, Chrome has no problem with the same exact URL. Using http://<server>:<port> works fine.

[Johnny Billquist]

What Firefox is that? I'm running 67.0.4 on OSX, and have no problems
connecting using http.

Johnny

> *http://shadowtron.com:81/cgi_bin/login.cgi
> <http://shadowtron.com:81/cgi_bin/login.cgi>
> *http://shadowtron.com:81/cgi_bin/get_status.cgi

> <http://shadowtron.com:81/cgi_bin/get_status.cgi>
> http://shadowtron.com:81/favicon.ico
> <http://shadowtron.com:81/favicon.ico>
>     This one might be a probe to see if the webserver is IIS.
> Anyhows, IIS's favicon.ico waits behind this URL.
>
> -Neil
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/502b33cc-20ab-4141-a9d0-e460243586bb%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/502b33cc-20ab-4141-a9d0-e460243586bb%40googlegroups.com?utm_medium=email&utm_source=footer>.

[sunnyboy010101]

Same. I've seen the behavior before - I probably have to clear all the caches and all that nonsense. Firefox has recently been showing a bad tendency to "know better than the user" when it comes to browsing.

> an email to pid...@googlegroups.com
> <mailto:pid...@googlegroups.com>.

[ShadowTron Blog]

I came home to a crashed system this afternoon.  :)

# Unexpected net trap (0)

ka6 4602 aps 147304

pc 121774 ps 50100

panic: net crashed

syncing disks... done

dumping to dev 2401 off 1024

dump succeeded

HALT instruction, PC: 007046 (JSR R5,3162)

sim>

I rebooted, ran fsck which was clean and finished the system up into multiuser mode.

Looking at the log from the webserver I didn't see anything unusual, normal traffic patterns.

Don't know if this is a bug in my logging code or something else. :)

Anyhow, i thought I'd share. -Neil

[Aaron Jackson]

We gave out the link to the web server running on my PiDP-11 on
Computerphile. The initial load of traffic crashed the PiDP-11, but also
my ERLite-3 router and knocked me offline for 30 minutes or so. Since
then it has been completely stable and served its page over 10k times,
although I had to move the image to an actual web server to deal with
load. I could probably move it back now that the traffic has
reduced. It's been fairly stable from what I can tell.

Here is the link to the video if you are interested:
https://www.youtube.com/watch?v=0n3UFtiyxwA

Neil, would you mind sharing your logging code? I'd like to add it the
version on GitHub. Alternatively, feel free to send a pull request if
you are ok with sharing.

Thanks,
Aaron

[Johnny Billquist]

There are most likely bugs and issues with the whole networking in
2.11BSD meaning that outsiders can bring your whole system down when
they start probing.

Which is what I suspect is what happened to you here.

Johnny

[Aaron Jackson]

I suspect it had more to do with several hundred people trying to
connect at once. Only took a 30 seconds or so after the video was
published. :)

Aaron

[Johnny Billquist]

The system should not crash just because it get hit by a lot of
requests, probes or whatever.
It is a bug if it does crash in that situation.

I've had to sort out plenty of those things for my TCP/IP for RSX.
Nowadays, it can deal with pretty much anything thrown at it even being
fully accessible on the internet, and using the standard ports.

But believe me, as an author of such code, I could not even begin to
imagine, beforehand, all the weird stuff that gets thrown at the system,
and all the weird corner cases that I have discovered.

Johnny

[ShadowTron Blog]

I'm new to github; I "think" I generated a pull request but .......  The last source code control system I used was Source Depot in the late 90s at a little company in Redmond, WA. 

Spent the morning adding logs for both a file and page counts.

Sharing the code is of course no problem, glad to do so. Having too much fun to not share.

-Neil

[leosam]

Thanks! I've installed your version and logs are now working. 

Now that I have logs, I'm okay to publish the website address:

http://leosam.net:9688

Would be good to see the source IP addresses in the logs. I will try to look into that when I finish grading exams!

Leo

[ShadowTron Blog]

I've been looking to get the source IPs as well. As far as I can tell inetd knows these but doesn't pass them on to httpd.Hoping you have better luck with this then I did.

I put up a new version of httpd this morning. The source can be grabbed via the link at http://shadowtron.com:81/ - Once I actually understand github it will get posted there as well.

What's been added:

  * Counter for the number of .html pages sent

  * Counter for the number of files sent

  * Code to dump some stats as a webpage   http://shadowtron.com:81/dumploginfo  will dump the page and file counts as a formatted html page that is auto generated when needed.

     * Code to generate a simple web page on the fly

  * Comments - lots and lots of comments

I really need to clean the source up, getting too much code in a single source file for my taste.

-Neil

[ShadowTron Blog]

The animated gif on your page is awesome, I've been wanting to do this. I'm jealous. :) I'll be linking back to your page.

Can you tweak the link to my page, not shadotron - it's shadowtron - short for "In the shadow of the electron"

On Sunday, June 23, 2019 at 7:17:05 AM UTC-7, leosam wrote:

[Craig Ruff]

> On Jun 23, 2019, at 10:32 AM, ShadowTron Blog <shadowt...@gmail.com> wrote:
>
> I've been looking to get the source IPs as well. As far as I can tell inetd knows these but doesn't pass them on to httpd.Hoping you have better luck with this then I did.

Look at the man page for getpeername. Use it on the file descriptor of your socket connection to the remote side.

[Johnny Billquist]

Uh. Anyone can find out who is at the other end of a socket.
The C call for this is getpeername(2).

If you just have a shell script, you can't call getpeername(2) directly,
of course. Write a small C program that just extracts that from stdin,
and run that from your shell script.

Johnny

On 2019-06-23 18:32, ShadowTron Blog wrote:
> I've been looking to get the source IPs as well. As far as I can tell
> inetd knows these but doesn't pass them on to httpd.Hoping you have
> better luck with this then I did.
>
> I put up a new version of httpd this morning. The source can be grabbed
> via the link at http://shadowtron.com:81/ - Once I actually understand
> github it will get posted there as well.
>
> What's been added:
>   * Counter for the number of .html pages sent
>   * Counter for the number of files sent
>   * Code to dump some stats as a webpage   http://shadowtron.com:81/

> <http://shadowtron.com:81/>dumploginfo  will dump the page and file

> counts as a formatted html page that is auto generated when needed.
>      * Code to generate a simple web page on the fly
>   * Comments - lots and lots of comments
>
> I really need to clean the source up, getting too much code in a single
> source file for my taste.
>
> -Neil
>
> On Sunday, June 23, 2019 at 7:17:05 AM UTC-7, leosam wrote:
>
> Thanks! I've installed your version and logs are now working.
>
> Now that I have logs, I'm okay to publish the website address:
>
> http://leosam.net:9688
>
> Would be good to see the source IP addresses in the logs. I will try
> to look into that when I finish grading exams!
>
> Leo
>
>
>
> On Saturday, June 22, 2019 at 10:48:38 PM UTC+2, ShadowTron Blog wrote:
>
> I'm new to github; I "think" I generated a pull request but
> .......  The last source code control system I used was Source
> Depot in the late 90s at a little company in Redmond, WA.
>
> Spent the morning adding logs for both a file and page counts.
>
> Sharing the code is of course no problem, glad to do so. Having
> too much fun to not share.
>
> -Neil
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/86b52d31-d958-4f67-8933-f1faeddcc14a%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/86b52d31-d958-4f67-8933-f1faeddcc14a%40googlegroups.com?utm_medium=email&utm_source=footer>.

[leosam]

Oops, that is indeed a typo. I'll fix it as soon as I get home.

Thanks! Sure, please link back!

[ShadowTron Blog]

Thanks, fingerd.c had source I was able to use to add the incoming IP info to the page, worked first try.

-Neil

[ShadowTron Blog]

A quick update. My PiDP11 and little webserver has been up and running for over 21 days straight. From the stats page on the little webserver:

Stats for STB's PiDP11/70 WebServer running BSD Unix 2.11

• The current time is: Sat Jul 13 08:36:28 2019

• System has been up: 21 days, 15 hours and 34 minutes

• Connection is from c-73-118-211-65.hsd1.wa.comcast.net

• I've served 562 html pages

• I've served 1288 files

• CTL_KERN:KERN_MAXPROC:122

• CTL_KERN:KERN_HOSTNAME:pdp11-211bsd-stb

• CTL_KERN:KERN_OSRELEASE:2.11

• CTL_KERN:KERN_OSREV:122

• CTL_KERN:KERN_OSTYPE:BSD

• CTL_KERN:KERN_POSIX1:0

• CTL_HW:HW_MACHINE:pdp11

• CTL_HW:HW_MODEL:70

• CTL_HW:HW_NCPU:1

• CTL_HW:HW_BYTEORDER:3412

• CTL_HW:HW_PHYSMEM:3932160

• CTL_HW:HW_USERMEM:2384320

• CTL_HW:HW_PAGESIZE:1024

• Load Averages: 1 Min:0.35 | 5 Min:0.23 | 15 Min:0.01

• Web Server Version: 20190630-1

[John Kennedy]

That's better than Twitter's servers. You should offer them your services.

[ShadowTron Blog]

I've been up over 35 days now, really happy with the stability of the PiDP11 and 211BSD. I took the small patch for the front panel LED issue and haven't seen an issue since then. :)

-Neil

Stats for STB's PiDP11/70 WebServer running BSD Unix 2.11

• The current time is: Sat Jul 27 06:36:09 2019

• System has been up: 35 days, 13 hours and 33 minutes

• Connection is from c-73-118-211-65.hsd1.wa.comcast.net

• I've served 790 html pages

• I've served 1853 files
• 
  

[Chase Covello]

Hi everyone,

I've recently made these changes to httpd.c, which I'm running on my PiDP-11 at http://chasecovello.ddns.net/:

1) Logging with source IP, date, HTTP request, response code, and file size or error message. Make sure /usr/adm/httpd.log exists and has correct permissions or all requests will return an HTTP 500.

2) Rudimentary CGI support. It will execute non-setuid/setuid binaries only if they are in a path that includes /cgi-bin/ somewhere. It doesn't pass an environment because I didn't need it.

3) More robust error checking and some buffer overrun fixes.

4) Use of a buffer and fread/fwrite to serve the file instead of fgetc/fputc. It's noticeably faster now.

I haven't done any C programming in a long time, so I've probably still missed some security issues. I welcome any comments. Source is attached. Thanks!

-Chase

[leosam]

Testing it on my website. So far so good!

Still havent tested the cgi-bin so far but I'll be testing it soon. BTW I've included a link to your website if you don't mind.

Leo

[Chase Covello]

Great! I appreciate that.

I've attached a new version with better detection of directories vs. files. It also won't crash if there's an error getting information on the connected socket, and there's another fix for a buffer overrun on the request handling code.

On Monday, August 19, 2019 at 6:16:43 AM UTC-7, leosam wrote:

Testing it on my website. So far so good!

Still havent tested the cgi-bin so far but I'll be testing it soon. BTW I've included a like to your website if you don't mind.

[Richard Stofer]

Very nice!

I finally got favicon.ico worked out and it is being delivered and displayed.  Onward and upward!

Now I need to go back to my early books on HTML.  There must be something cool I can do with the web server.

[Chase Covello]

I've made a few more changes since the last version; I will be including this one in the new 2.11BSD disk image for testing. I think it's time I set up a github repo, but for now the new httpd.c is attached, along with a Makefile to make rebuilding and installing easier.

The big changes are:

• Added a 60 second timeout to kill the httpd process if the client fails to complete the HTTP request. I noticed after a few days I have several httpd processes sitting there and I got tired of manually killing them.
  
• Changed document dir to /home/www because /home has much more free space than / on the PiDP-11 2.11BSD disk image.
• Tuned the buffer size to save memory; testing shows little to no performance improvement beyond 64 bytes when serving big files. I went with 256 for no real reason other than it's not too big and not too small. Below are the test results for a 30MB file from my system:
  

BUF_SIZE    SPEED (kB/s)
    1            20
    2            36
    4            44
    8            90
   16           120
   32           120
   64           125
  128           125
  256           125

--Chase

[David Read]

The CGI capabilities of this server caught my attention, and I added a few more features to keep my PiDP-11 busy :)

For GET requests, a QUERY_STRING variable containing the query will be placed in the environment for the CGI program. POST places all the headers and a CONTENT_LENGTH variable in the environment. Also, I switched the httpd request processing of stdin into unbuffered mode so that the content is available to the CGI application after the server processes the headers. 

I created a proof-of-concept CGI app, Dr. Nim, for those old enough to remember him.

I've attached the updated code but also housed it in a GitHub repository: https://github.com/DaveRead/2.11BSD-httpd

The Dr. Nim game code can be found at https://github.com/DaveRead/2.11BSD-Dr.Nim

-Dave

[Jeff Spears]

Thank you!