Netcat ( nc -l ) as webserver

Linux and Unix-Like Emergency UNIX and Linux Support
1

Dear Linux guru's

I am trying to create a webserver using nc (netcat only) on RHEL 7.2 running on bash shell.

now the easy thing is to get nc listing to a port and respond back

$ while true; do { echo -e 'HTTP/1.0 200 OK\r\n'; set; } | nc -l 7877; done

This when called from a browser: http://My-server:7877 I get my env variables. Works perfect !! Love it :slight_smile:

Now when I try http://My-server:7877?asd=1&something=2&other=hello

I was hopping to get QUERY_STRING env variable with all the values sent via browser GET method ! . However the env variable is not set. There is not variable set with these values.

Versions:

Bash
GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu)

nc
Ncat: Version 6.40 ( Ncat - Netcat for the 21st Century )

redhat
Red Hat Enterprise Linux Server release 7.2

Dont want to use anything other than nc. Cannot install any tool or webserver or binaries. Please dont suggest that

And thanks all for reading my question :).

2

Sorry, that - and the entire rest of the common gateway interface - is something a web server does for you.

3

I made a named pipe and seems very close to getting my solution of garbing HTTP headers, Also noticed my browser does not Always send all the header each time.
(Chrome Version 54.0.2840.99 even in incognito )

My workaround (not solution) have a named pipe to communicated with nc.

$ mkfifo  webout

and then have the while loop to feed netcat(nc)

while true; do { echo -e 'HTTP/1.0 200 OK\r\n'; cat webout;  } | nc -vl 8080 >webout; done

I am just playing around with named pipe, looking to find something in the lines of:

nc -l PORT <webin > 2&1>webout

and then loop out with tail kind of thing on webin and webout. Any experts on FIFO's please suggest.

4

This is going to be a royal pain to do in the shell. You're going to get stuck waiting on input from the web service while the web browser is stuck waiting on input for you. Named pipes are prone to this, even used one-way -- using a pair means almost guaranteed deadlock.

If you have Python or Perl, I'd look into writing it in that language instead. You would use a socket directly, avoiding the need for these deadlocks.

Another alternative, which I know you didn't want, would be the expect language. It can work pretty much the way you were expecting - run a program, check if it's got input, check if it's got output, decide what do do with it, move on.