One thing that annoys me quite a bit is how Adobe Connect handles HTTP status codes. Essentially it’s doing it in the wrong way (from my point of view at least), but let me explain.
You might just know Adobe Connect from using Adobe’s hosted SaaS, but Adobe sells Adobe Connect as a so called licensed version – you buy licenses and can host it yourself within the IT structure of your organisation. Adobe Connect 8 is a Java-based web application that’s bundled with Apache Tomcat.
When users upload content such as slides, videos, documents etc to the Adobe Connect server, Connect will ask the user to provide a server-unique URL – if the user doesn’t, Connect will store the content under a self-created and unique URL.
Essentially, you might end up with something like http://yourserver.whatever/myContent or http://yourserver.whatever/p/6554787856. That’s usually fine because if the requested content item is available, Adobe Connect will return the content and the HTTP response has an HTTP status code of 200 – as it should be.
It gets interesting as soon as the user requests a URL that doesn’t exist. This might happen accidentally (user error or typo) but in some instances it also might happen on purpose. For example: One is loading 3rd-party eLearning courses into Connect that use their own course content launcher – which would as such during the initialisation of the course test the existence of some files on the HTTP server it’s running on. In such a scenario, the course launcher might or might not request a resource that doesn’t exist.
Now – we all know what a good HTTP server would do here, right? Correct – it would return an error page of some kind and the HTTP status code would be 404. This is what HTTP servers do for quite a while now.
Not Adobe Connect though. If one requests a non-existing resource it will return a nicely designed error page, but the HTTP status code of the response is 200 for “OK”. Clearly that’s not the intention of the semantic of the HTTP protocol. I can even see where that thinking is coming from – the Connect web application is returning a pretty page, so from the point of view of the developers it might even be a valid request. Unfortunately this type of thinking fundamentally breaks the web.
By now you have surely figured out that I actually had to deal with exactly this scenario. I had a look into a few options of tweaking both the Tomcat as well as the Adobe Connect configuration but can’t see an easy solution. The best idea I can come up with is writing a ServletFilter that intercepts the HTTP response and modifies the HTTP status code to what I want it to be.
The problem with this solution though is that it’d be an annoying hack and would prob. be broken after the next Adobe Connect 8 Service Pack. The only criteria for me to actually know if the status code has to be changed would be the content of the response payload. If said content looked like an error page (maybe I could grab the page title – but then I’d have to deal with it in multiple locales to do it properly), this would be the indication to change the HTTP status code to 404. I suppose everyone can say why this gets more hacky by the minute…
Obviously we logged a support ticket with Adobe’s Enterprise Support – unfortunately without result. According to Adobe it’s not possible to achieve what I want to do here (simply getting a 404 status code if the resource doesn’t exist). If anyone has another good idea as an alternative to the ServletFilter I mentioned in the paragraph above – please let me know.
Comments on this entry are closed.