Okay, that was quick. Managed to get Apache registered to systemd as well. So now we have both of the processes Jaxer and Apache registered of services and that means that we can safely remove the entire scripts folder (yay!). For Apache, the /etc/systemd/system/apache-server.service file is written below.

So now that we’ve managed to separate Apache from the runtime environment by using Nodejs, that means we were able to simplify the start and stops scripts directory to remove the scripts related to Apache. And now that we only need to start and stop Jaxer, that means it should be considerably easier to register Jaxer as a service to systemd. So after a little bit of trial and error we were able to get the service to work.

So in the previous post we rounded out our Apache emulator for Aptana Jaxer, which uses Express and Nodejs to act as a front-end file server and then uses Jaxer to handle calls to the server. While not complete it looks like we have a decent amount of functionality implemented with the basics being passing html files and callbacks to Jaxer to be handled.

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.

So in the previous post we were able to proxy and http request to mod-jaxer by mimicking the format that Apache uses to pass to modules. And we were able to get the point to where we get a response from Jaxer. And Jaxer uses the same format to return a response that we use to pass in.

In the previous blog post we broke down the binary data format that Apache used to communicate with mod-jaxer. In this post we will cover how we handle taking an http request, and converting it to a binary package that can be recognized by mod Jaxer.

On September 5th 2019 I was able to give my first live seminar for Jaxer hosted by OSSAJ. This was my first time presenting for an what was supposed to be an hour long seminar. In terms of presentation style I think the most important aspect is to relax, and I think I was able to do that better during the Q&A session.

In our previous post we started to analyze the relationship between Apache and mod-jaxer by capturing the packets that were exchanged between these two processed. We found that first some handshake bytes were exchanged followed by headers and the content of the file being handled by Apache. As this looks like the main functionality we will have to replicate, in this blog post we will take a closer look at the header data sent by Apache.

In this blog we will be continuing with the theme of replacing Apache for the purposes of simplifying the post-install Jaxer environment. So we have Apache which accepts http request, and we have mod-jaxer which processes the requests received from Apache. So we need to figure out how these two processes interact with each other.

So the next objective we have is to start replacing Apache. We can do this by analyzing how Apache interacts with mod-jaxer. And if we can find out how to mimic Apache, then we can replace Apache with our own server.