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.

From there we’ve added in a few more quality of life features. One of the them that we now forward the ‘Set-Cookie’ parameter from Jaxer. This is something that I left out intentionally while testing as I wasn’t sure on how to handle cookies. Jaxer tries to aggressively set a cookie on the client side for Jaxer to be able to manage sessions for a given user, even if they are not authenticated on the server yet. I think it was intended for tracking things like number of login attempts.

The thing is that we probably don’t want or need Jaxer to set cookies that aggressively. The EU law requiring websites to show that they use cookies is one thing. The other also comes down to the implementation. We might only want to set a cookie on a specific path, or set same-site to strict, or potentially change the length of how the long the cookie is valid.

But for right now I only have the cookie being set on the callback functionality and not for the html side of things. And for now that seems like a reasonable adjustment until the issue comes back up again. I’d be tempted to manage cookies with Nodejs and include some kind of encrypted hash, or maybe set the calling page and timestamp in the cookies so we don’t need to include them as arguments to the server in the XMLHttpRequest object, as they would be auto-included by the browser.

Another adjustment we made was to check for a directory root, see if there is an index.html file and serve the index.html file if exists, otherwise we serve the directory listing. Nothing groundbreaking, but in terms of mimicking Apache’s functionality, this a small nice to have feature.

In terms of things that haven’t been implemented, there’s probably a lot more, but for now we’ll list them to be aware of and address them if and when they break. For the protocol headers we don’t know what happens if the length of a string exceeds 255 characters or the limit of one byte. We’re also using a lot of fixed values that could go one of two ways. On one side we might want Jaxer to act as a state-machine where it only gets a limited set of data and performs a very specific function based on the information it has. On the other hand we also might want to pass in all of the information received from the client as-is to allow it to be exposed to the functionality.

I’d be on the side of the fence that since we’re using Nodejs as our http-server, it means that we could front-load a lot of the authentication aspect and only pass information back into Jaxer on the premise that the origin has already been confirmed. But also out of curiosity, I’d be interested to remove as many of the headers being passed into Jaxer as possible to try and identify the minimum of amount of information for Jaxer that is required to function, and then scale up the number of headers being passed from there.

In terms of other limitations that we have not addressed, is that the length section of the protocol only uses two bytes. So we need to figure out what needs to be done in terms of the protocol for http-bodies that exceed 0xffff bytes. Though for the moment we’re probably going to be using small debug pages, so we’re probably okay on size, but we’ll leave Apache around in a functional state to be able to record packets if and when something breaks.

So for now we have a functional working Apache emulator (or maybe more fitting might be an approximation), for Jaxer. And while the emulation could be a lot more elegant it works for what we need right now. I’ve published the code to https://github.com/wsdCollins/ApacheEmu, and I’ll be updating and changing it as needed. For now I will set it up and keep it running with pm2 while I work on simplifying more of the Jaxer runtime environment. And I think the next thing I want to work on is cleaning up the start and stop scripts.