Apache Update Today

I take the unusual measure of hosting this site, and this blog, on my home computer, which I name ‘Phoenix’. This requires that I forward all requests to my URL, to My Home IP Address. Hence, if you’re on a Linux computer and want my current IP address, you’d just type in:


host dirkmittler.homeip.net



But of course, in order to host a Web-site, I also need to be running a fully-configured Web-server. Under Linux, this pretty much implies running Apache.

The version of Apache on this box was just updated this evening, to version ‘2.4.10-10+deb8u10‘. When the server is updated like this, a post-install command is also given to restart it, since otherwise the new software will not have been loaded into RAM, nor running. But this should not cause much of a disruption, because essentially it just causes a connection to disappear for about 2 seconds.

The reason for that would be, the fact that each HTTP Request is handled separately, and after each HTTP Request has fetched a page, or an update to a page, the CGI-Script that did so exits. This means that if the reader is noticing a ‘stateful session’, which has persistent data from one page-reload to the next, this actually requires that a database act as a back-end to the site, and that the Web-server’s CGI-Scripts can act as a client to that database. And cookies on the browser, in certain cases, identify a session. For readers of this blog who are not logged-in, such cookies are not being used.

In my case, it’s a MySQL server.

One thing that might however happen to a reader, due to such a server-restart, is that an established session gets interrupted momentarily. This would have happened around 19h45 this evening.

The reason that can happen, is the use of Web-sockets on this site. Essentially, only the browser’s initial request to connect, is actually made to Port 80 of the server. After that, the session of one particular browser (client) is handed off to a Web-socket, which is actually some obscure port on my computer, owned by an Apache sub-process.

If the sub-process is killed, any browsers that were still connected to it would have experienced a disconnection. Because browsers tend to ‘remember’ which Web-socket they were connected to when simply prompted to reload a page, this disconnection might last until the reader restarts his browser.

My Site mainly Requires Web-Sockets.

The origins of HTTP were essentially ‘sessionless’. This meant that with a server always listening on Port 80, a client could request one URL at a time, in response to which the server would return the page in question directly to the client’s port number. This included the CGI-scripts’ FORM data. But as the early Internet evolved, Web-sites started to become ‘session-aware’. I explained this to my friends in the past as follows:

The client connects to the assigned port number 80 on the server, and requests a session, which causes the server to start listening on another port number, this forming a ‘session socket’. The one listening on port 80 was the ‘server socket’. The server’s session socket was dedicated to one client and to one session.

My friends did not acknowledge this description of how TCP works, I think mainly, because I did not use the right terminology. What I had referred to as a ‘session socket’, is officially termed a “Web-Socket” in the case of HTTP. It turns out that with an Apache server, many sub-processes can bear these Web-Sockets. They don’t exclusively exist in order to output Web-pages at a faster rate, in response to individual requests made by the clients, to the process still listening on port 80.

One fact to know about my site, is that for such purposes as viewing this blog, the use of Web-Sockets is required. In the case of certain other sections of my site, such as http://dirkmittler.homeip.net/GallIndex.htm, the use of Web-Sockets is not required, because those Web-pages exist mainly in a sessionless way – they can be fetched one at a time without error.

Certain proxy-servers will not allow a Web-Socket to get forwarded. These are logically also proxies which don’t allow SSL connections to be forwarded, because the encrypted SSL data is also sent via Web-Sockets or their equivalent. If you are connecting to the Internet via such a proxy, I’m afraid you won’t be able to navigate my blog correctly. I apologize for this, but there is little I can do about that. I think that you should still be able to fetch a single posting of mine, that comes up through a search engine.

Dirk

(Edit: ) This may also apply if you’re trying to connect to my IPv6 address, because my IPv6 is being provided by a Teredo proxy, which might have just assigned reduced privileges to my client:

Previous Post