Adobe Connect API in Connect 10 – Changes to HTTP response/requests

Note: This blog article is only applicable to developers of applications that use the Adobe Connect Web Services (XML API) to integrate external systems with Adobe Connect.  If you are not familiar with the Connect API and are not developing any applications that integrate with Adobe Connect via web services, you do not need to worry about the content in this article.

With the recent release of Adobe Connect 10.x, Adobe updated the internal web server for the Connect application to Tomcat 9, because Tomcat 8 was ‘End-of-life’ (EOL) as of June 2018.  While there have been no major application or configuration changes because of this, we have observed a couple of changes that ‘could’ impact integrators or consumers of our XML APIs.   

This is what has changed:

1\ HTTP/1.1 responses to successful requests no longer have a reason phrase. So what was previously HTTP/1.1 200 OK will now be just HTTP/1.1 200 (note the missing OK). If you are interested, https://bz.apache.org/bugzilla/show_bug.cgi?id=60362  has discussions around this. Anyone relying on the reason phrase in responses will need to modify their implementation accordingly. 

2\ HTTP/1.1 requests no longer allow empty or null host headers. This is the result of a security fix in the latest Tomcat patch.  In general, browsers are already compliant so we do not believe there is any actual danger of end user issues. But there might be clients that are not compliant – If for example, you have F5 load balancers that are configured to send empty host headers. The requests will not succeed until you modify the host header to have an actual value. 

Also, just to clarify in case the above is still not clear… there are two possible places where you get an “OK” based response –

1. One is the HTTP response header, for every successful HTTP request, and is of the following form – this is where the ‘OK’ has been dropped in Tomcat 9 (in Adobe Connect 10.x):

   HTTP 200 OK

2.  The other is in the body of the HTTP response to specific requests, constructed by the application, such as testbuilder calls (from Connect) or web service API calls:

   status-ok
   <status code=”ok”/>

** this above the most common ‘ok’ response that developers refer to.

There is only a slight change (1), since that is internal to the web server and the implementation has changed in Tomcat 9. The latter, (2), is something we code for in the application, and this has not changed in Connect 10. 

In short, we are not changing anything substantive with regards to the HTTP framework itself in the application with Connect 10 – but Tomcat 9 is making that slight change (1), and the question is whether any integration is depending specifically on what Tomcat 8 was using/sending.  It of course is a possibility and if you notice no difference in your API/application workflow and performance, this most likely does not apply to you.