Does CFHTTP Handle File Attachments Wrong?
I recently ran into an issue when interacting with Mailgun's API via CFHTTP whenever we attempted to send a file attachment. The problem is that the recipient's email attachment file name always contains the full path of the file as passed to the cfhttparam file attribute.
For example, if my actual filename was "Sample_Adobe_PDF_Document.pdf", Mailgun would send the attachment as "c:myfilesdocumentsSample_Adobe_PDF_Document.pdf". Weird right?
I created a dummy API endpoint on beeceptor.com to see what CFHTTP was sending Mailgun, and this is the header that ColdFusion sends:
Content-Disposition: form-data; name="attachment"; filename="c:\myFiles\documents\Sample_Adobe_PDF_Document.pdf"
Content-Type: application/pdf
At first I figured this was a problem with Mailgun and that they weren't properly parsing the filename, from the POST data. However, when I look at the web specifications for Content-Disposition Filename, it says:
"Is followed by a string containing the original name of the file transmitted. The filename is always optional and must not be used blindly by the application: path information should be stripped, and conversion to the server file system rules should be done. This parameter provides mostly indicative information. When used in combination with Content-Disposition: attachment, it is used as the default filename for an eventual "Save As" dialog presented to the user"
ColdFusion requires the full path of the file be used in cfhttparam, so I don't think this is a mistake from my end. It also doesn't make sense for ACF to reveal the full internal path of the file in a POST request. Some might argue that sending this data is a security concern.
I tested this in ACF 2016, ACF 2018, and ACF 2021. All versions include the full path of the file in the POST request.
What do you think? Let me know if you think this is a bug and I'll create a ticket.
