AOLserver Virtual Hosting with TCP

His next attempt at uploading stuff gave the "Error writing content: resource temporarily unavailable" error in ns_conncptofp, after about 4 minutes of uploading. WTF was going on?"

So in trying it myself, the upload of an image would just hang. I didn't know if it was due to the new satellite internet system we have which replaced a very bad ISP (avoid Alltel for any of your business dealings), or some weird Mac+Mozilla issue.

I wanted to see what traffic was happening on each of the servers (the front-end and the badgertronics back-end). Was anyone receiving any data? Only part of it? Was some stuck in the queue on my end? After a bit of poking around in the code I discovered that Ns_SockRecv() in nsd/sock.c is the call that does reading on the sockets. I stuck in this right before the return

    {
	int i;
	int blah;
	unsigned char saved;
	blah = (nread == toread) ? nread - 1 : nread;
	saved = ((unsigned char*)buf)[blah];
	((unsigned char*)buf)[blah] = 0;
	for (i = 0; i < nread; i++) {
	    Ns_Log (Notice, "TRACE: %d: %x : %c", i, 
		    ((char*)buf)[i], ((unsigned char*)buf)[i]);
	}
	Ns_Log (Notice, "TRACE2: %s", (unsigned char*)buf);
	((unsigned char*)buf)[blah] = saved;
    }

The front-end was getting all of the data, so it wasn't sitting in some modem buffer. The back-end was getting all the header data, but none of the image data. It was stopping right after the MIME header in the HTTP POST for the image which declared the rest of the data to be a GIF image. I wasn't sure why it would be doing that. Maybe something was looking at the data and only reading header information. Looking closer at the output there was a zero byte there. How suspicious. I used emacs to change all of the zero bytes to 1 bytes in a gif file and uploaded that. Almost instantly I got a "this is a corrupt image" from the identify program, so it definitely it wasn't connectivity issues on my end. The zero byte is the culprit. That means someone is assuming the data is pure text and nothing binary. There's probably a call to strlen() somewhere in the process.

Working backwards from ns_conncptofp, everything looked like it was doing the Right Thing on the back-end, everyone passing lengths of buffers around. So the back-end was doing everything right. Looking at the nsvhr code, I found SockWrite() doing a strlen(), and that gets called in the TCP path of the virtual hosting. The call to strlen() was unnecessary since we could easily get the length of the data to be sent to the back end. Explicitly passing in a length fixed the problem, plus made it a hair more efficient, since strlen() is an O(N) operation, having to walk over every byte in the string.

So why the "Error writing content: resource temporarily unavailable" error in ns_conncptofp? That particular error is coming from NsTclWriteContentCmd, and the actual error is happening on the reading from the socket, rather than the writing to the file, so the error is misleading. The "resource temporarily unavailable" is simply the EAGAIN errno, meaning something timed out, try again. In this case, the timeout is waiting for more data from the front-end, which isn't coming since it stopped at the zero byte. The timeout happens, EAGAIN is returned in errno And why was Kevin able to upload photos previously? He did those while I was still struggling with nsunix as the transport mechanism between the front-end and back-end. Recently was the first time he's uploaded photos since I made the switchover.