Hand crafted AXL scripts and HTTP/1.x

In my current day-job, I sometimes create hand crafted pieces of AXL scripting for some of the trickier reporting aspects of auditing of provisioning process. These AXL scripts will most probably these days be crafted in Java, as I like the eclipse development environment which makes it very easy to debug these scripts (I’m not a professional developer – just someone who went to university and was taught how to write code in many languages). Just before I went away for my month to Australia and the CCIE Voice Lab, I had some reports that my script wasn’t working. Often these are just minor issues like a user not having AXL privileges or the input file format not being quite right, but this one was different – the script worked fine on our CUCM 6.1.3 and CUCM 7.1.5 servers, but not on our newly upgrade 6.1.5 servers.

So after that month off, I came back to reports that it still wasn’t working and could I investigate. So I fired up eclipse and dived right back into debugging mode. The response I was receiving from CUCM was “HTTP/1.1 400 Bad Request” – this I was not receiving from the other servers (i.e the none 6.1.5 clusters). I could not work out what was going wrong – I tried forcing the authentication to fail – still the 400 errror. I compared to other pieces of had-crafted AXL that we have, and they looked the same as mine. In the end I was on the point of giving up when I noticed in an example on Cisco’s developer site that one code snippet had the following:
        POST /axl/ HTTP/1.1
whereas my code had:
   POST /axl/

So I hunted through CUCM release notes for any mention of this change – no luck. I checked the tomcat release notes (having noted that the tomcat version changes between 6.1.3 and 6.1.5) and still no luck  - although there were a lot of changes related to POST processing. Checking the original http RFC-1945 states that “

The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.”

However it seems that the tomcat within CUCM does not any longer adhere to that (although I can’t find this documented) and follows the HTTP/1.1 RFC-2616 section 5.1 which explicitly states that a request must have the HTTP-Version.

So I changed my code to contain the HTTP version and like magic it worked again. If only I used less hand-crafted scripts this would never have been an issue!