Some of you might have read my post on Cfdocument Performance. One of the tips in that article is to watch out for external resources. If your HTML is pointing to images or css files (as opposed to "in-line" CSS), cfdocument will have to "go get" those files. The way it does this is important. The server does not does not simply "include" the file (a la cfinclude). Instead, cfdocument impersonates a browser and uses HTTP. This has an impact on how you use Cfdocument. Each cfdocument call has the potential to generate many http requests. Here are the details.
When cfdocument goes to "get" those outside resources it uses the host header of the request. When you request a cfdocument that has an embedded image with a relative path it will use HTTP to "get" that image and format it for inclusion the PDF file. That means that the SERVER has to be able to resolve the IP or URL or whatever that you are using. This can really fool you. You end up with a cfdocument call that takes a long time and the result has broken images or missing css. Your first inclination will be to try and resolve those images in your browser. That's not going to work. Even though the request is running in your browser, it is the server that is going to make the HTTP request to "get" those images. So you would have to browse to the missing image in the "server's" browser to make any sense of it. In other words, troubleshoot missing images in cfdocument just like you troubleshoot problems with CFHTTP.
This is an important optimization point as well. The more items you include in a cfdocument that are "outside" of the calling page the more requests you generate to your server. So if you had a document that included a 100 thumbnails it would require 101 http request to generate the page (the calling request + 100 additional requests) even if the file sizes are very small. A nice enhancement would be support for the "file" request type so we could add an img url like this:
I'm glad you asked. You may know that SSL certificates are tricky business with CFHTTP. If you are using an SSL cert that is not "trusted" by the JVM the request will fail. By default the JVM trusts big names like Verisign, Thawte and the like. If you are using Open SSL or a self issued cert (or any cert not trusted by the JVM) the http request will not work. It will not be able to successfully negotiate the socket. The good news is that you can manipulate the JVM keystore. The instructions may be found in a previous post of mine titled SSL and the Trusted Keystore in Java. The article is pretty old and applies to version 1.3 - so if someone has an update I'm all ears. If you are building a document using cfdocument over an SSL request and you are seeing broken images this could be your issue.