Live data from Hacker News

Nweb: a tiny, safe web server (static pages only)

ibm.com

51–60 of 63 posts

Re: Nweb: a tiny, safe web server (static pages only)

#51
post #44

> if LINUX sleep for one second to ensure the data arrives at the browser can someone explain that please?

It's explained further down:

After the last byte of the file is sent, the nweb web server web() function stops for one second. This is to enable the file contents to be sent down the socket. If it immediately closes the socket, some operating systems do not wait for the socket to finish sending the data but drops the connection very abruptly. This would mean that some of the file content would not get to the browser, and this confuses the browser by waiting forever for the last bit of the file and often results in a blank web page being displayed.

Re: Nweb: a tiny, safe web server (static pages only)

#52
post #23
post #19

Adding to what everyone else has said, this also "how not" to write socket code; for instance, the assumption that you can read a whole HTTP request "in one go" with a single large read call is false. Also, casting function calls to (void) is nonsensical. You can perhaps forgive the sprintf() call because, AIX. (Believe it or not, there was a time when snprintf was a portability problem). You can't forgive the log()…

> Also, casting function calls to (void) is nonsensical. This is an older convention to indicate that the programmer knows the function returns a value but has chosen to ignore it. It got around the false positives generated by lint. This code uses SIGCLD which I don't think is supported by BSD, where it is called SIGCHLD and is slightly different (someone please correct me if I'm wrong). If that's the case, then the…

Confirmed the SIGCLD problem.

I had to change it to SIGCHLD to get it to compile on my Mac.

Re: Nweb: a tiny, safe web server (static pages only)

#53
post #51
post #44

> if LINUX sleep for one second to ensure the data arrives at the browser can someone explain that please?

It's explained further down: After the last byte of the file is sent, the nweb web server web() function stops for one second. This is to enable the file contents to be sent down the socket. If it immediately closes the socket, some operating systems do not wait for the socket to finish sending the data but drops the connection very abruptly. This would mean that some of the file content would not get to the browser,…

ah, sorry - i just read a part and ctrl+f'd for this, but searched for the wrong terms apparently.

would this cause connection timeouts if copying data to the socket took longer than one second? i'm always a bit sceptical when i encounter such seemingly arbitrary timing assumptions.

Re: Nweb: a tiny, safe web server (static pages only)

#54
post #19

Adding to what everyone else has said, this also "how not" to write socket code; for instance, the assumption that you can read a whole HTTP request "in one go" with a single large read call is false. Also, casting function calls to (void) is nonsensical. You can perhaps forgive the sprintf() call because, AIX. (Believe it or not, there was a time when snprintf was a portability problem). You can't forgive the log()…

The list of MIME types looks weird, too. There's stuff like "image/zip" in the source code.

Re: Nweb: a tiny, safe web server (static pages only)

#56
post #20

Earlier quoted context omitted.

> Also, casting function calls to (void) is nonsensical. Does extremely pedantic C require the results of function calls to be used? I know the correct way to mark a variable as unused is to cast it to void, but I'm not sure if you're supposed to do that for function return values as well.

Nothing about the cast is "required". However, it's good practice because the cast explicitly acknowledges the function has a return value that we're throwing out. Looking at the following function call: (void)create_widget(&widget); It's clear that `create_widget` returns some value -- it's probably an error code that tells us whether the widget creation was successful. The source code here says "I know this functio…

It's a terrible and (I think) amateurish practice that misapprehends the point of C's type checking while adding lots of visual noise, which is why you'll virtually never see it in well-liked C code.

Re: Nweb: a tiny, safe web server (static pages only)

#57

Earlier quoted context omitted.

Works fine for some tests, but it's single threaded. If you need concurrency: twistd -no web --path=.

Perhaps, but the use case it usually finds is "I need a webserver, here. Now." Python is nearly always installed, and that depends on nothing but the standard library. You can stick an alias in your dotfiles (I have, it's called "serve-this") and not have to worry about having twisted¹ getting to wherever your dotfiles get put. (I distribute my dotfiles over git/github, so it's really easy to move them around. More w…

Twisted is pre-installed on OS X and various Linux distributions...

Re: Nweb: a tiny, safe web server (static pages only)

#58
post #5

I am always on the look out for a small, lightweight and secure web server for impromptu file sharing. Right now I use publicfile from djb.[^1] My only complaint is that there is no debian package for publicfile so I have to build my own package. I would love to find an equivalent (ftp not necessary) daemon that is included in debian. Is anyone aware of a something in debian repos that I am overlooking? [^1]: http://…

Webfsd is in the Debian repos but the stupid person who packaged it created an init script for it as if you want to run it as a service rather than ad hoc. So you may as well build from source...

Or you could contribute something back and file a bug report, or maybe even a patch allowing people to use it either way. Certainly beats insulting someone you don't even know who was trying to make the world a little bit better by doing some free work.
Post reply on HN