So we’re reaching a point in the Apache emulation aspect of the simplification that I didn’t expect to reach this quickly, but either way I’ll take it. Now that we can take html files and pass them into mod-jaxer the next step is to actually be able to handle requests sent to the server.

The full story is that when Jaxer receives an html request it will look through the page for the scripts that are defined as runat=”server” or runat=”server-proxy”, and save those scripts on the server with a page name, timestamp, method names, and flags for if the script can be called from the client or not. Jaxer will then provide a small ajax library will callbacks to those functions already defined.

Next when the client makes a request via the client library, Jaxer will parse the arguments as “application/x-www-form-urlencoded” and send a POST request to “/jaxer-callback”. And then Jaxer will handle the request and then return the results back to the client with the XMLHttpRequest response as a JSON object string.

So since we’re replicating the interaction of Apache receiving the POST request, communication with Jaxer, passing in the POST body, and then returning the response back to the client. Which means that we need to go back our proxy server and record the interaction of Apache and mod-jaxer to be able to replicate the functionality with our emulator.

The good news is that since we’re already somewhat familiar with the protocol being used of passing information back and forth between the servers, the interaction ends up being more conceptual as opposed to focusing on any specific sequence of bytes. So the way the interaction works is that Apache starts off the conversation by sending handshake bytes to mod-jaxer. Mod-jaxer then responds with the same sequence of bytes.

This is where the main difference occurs, before we were able to send both the headers and bodies at the same time, but in this case even if we try the same approach mod-Jaxer completely ignores the body. So what ends up happening is that Apache sends the headers with an empty body. Jaxer then responds with the bytes of “0x05 0x00 0x00”, as if to say, “please continue”.

Apache then sends the bytes “0x06 xx xx”, where xx xx is the length of the body in bytes as big endian. Followed by the raw body, and then finally Jaxer responds with the same information as returned with the html request, and we can pass that into the same function we previously made to get the headers and content-body, and then return that to the client.

Replicating the functionality ended up not being too bad as we were able to re-use a lot of code from what we made before. There was an issue where Jaxer failed to handle the requests, and what we did to get around that was used the captured bytes as placeholders to see which part wasn’t working. And the issue ended up being that Jaxer requires the parameters “CONTENT_TYPE”, “HTTP_X_REQUESTED_WITH” and “CONTENT_LENGTH” to be defined or the request won’t work. So once that was fixed we were able to use our beautiful todo list without issue.

So now that we have most of the basic functionality in terms of handling both pages and function calls we can go back and add in a few quality of life features that should hopefully round out most of the use-cases for our Apache emulator.