Skip to main content
A
ACS LLC
Inspiring
March 26, 2018
Answered

An established connection was aborted by the software in your host machine

  • March 26, 2018
  • 3 replies
  • 24646 views

Since moving to CF2016 I've been seeing quite a lot of the error below in the exception log file. I did some research and can't quite figure out what is going on and if this is indeed having an impact on the end user. I've tested the download link on http://www.hiddentoolbox.com and it appears to work fine

"Error","ajp-nio-8016-exec-6","03/26/18","11:55:46","myapp","The cause of this output exception was that: org.apache.catalina.connector.ClientAbortException: java.io.IOException: An established connection was aborted by the software in your host machine. The specific sequence of files included or processed is: C:\ACS\hiddentoolbox\downloadfile.cfm, line: 15 "

coldfusion.tagext.OutputException: The cause of this output exception was that: org.apache.catalina.connector.ClientAbortException: java.io.IOException: An established connection was aborted by the software in your host machine.

I was wondering if this is as simple as people closing their browser before the download is completed, although I could not replicate myself by starting and closing a browser before it had completed.

Could anybody help throw some light on it?

Thanks

Mark

This topic has been closed for replies.
Correct answer ACS LLC

It does indeed work without the CFABORT and plain text, giving this (Will change to this as the right answer)

 

<cftry>
<cfcontent type="application/unknown" file="#downloadlocation#\toolbox.exe" />
<cfcatch>
</cfcatch>
</cftry>

 

3 replies

D
Dave Watts
Community Expert
January 23, 2020

I'd recommend that you remove the CFABORT and the plain text output in your CFCATCH - or at least try that and see if it's happening. I can easily see that breaking some clients downloading your files.

 

Dave Watts, Eidolon LLC

Dave Watts, Eidolon LLC
A
ACS LLCAuthorCorrect answer
Inspiring
January 23, 2020

It does indeed work without the CFABORT and plain text, giving this (Will change to this as the right answer)

 

<cftry>
<cfcontent type="application/unknown" file="#downloadlocation#\toolbox.exe" />
<cfcatch>
</cfcatch>
</cftry>

 

BKBK
BKBK
Community Expert
January 6, 2020

We might be able to throw some light on the matter if shared with us the code that caused the error. Namely:

C:\ACS\hiddentoolbox\downloadfile.cfm, line: 15 

Was it the cfcontent line you posted later?

 

A
ACS LLCAuthor
Inspiring
January 6, 2020

Here's the code

 

<CFIF #ISDefined('url.aff')# AND #ISDefined('url.sub1')#>
<CFCOOKIE NAME="aff" VALUE="#val(URL.aff)#" expires="never">
<CFCOOKIE NAME="sub1" VALUE="#left(URL.sub1,50)#" expires="never">
</CFIF>

<cfparam name="cookie.aff" default="0">
<cfparam name="cookie.sub1" default="0">


<CFSET downloadfilename = "HiddenToolboxInstaller" & "_a" & "#cookie.aff#" & "_r" & "#left(urldecode(cookie.sub1),50)#">

<cffile action = "append" file = "c:\acs\hiddentoolbox\control\logs\downloadfile_cfm.txt" attributes = "normal" output = "AFF:#cookie.aff# - SUB1:#cookie.sub1# - #now()# - #remote_addr# - #CGI.HTTP_USER_AGENT#">

<cfheader name="Content-Disposition" value="attachment; filename=#downloadfilename#.exe" />
<cfcontent type="application/x-msdownload" file="#downloadlocation#\toolbox.exe" />

 

 

D
Dave Watts
Community Expert
January 6, 2020

I'm going to make a suggestion. I'm not even sure I like this suggestion, but here goes. You might try making your download page unavailable to regular HTTP GET requests. Put it behind a form or something. Your problematic clients probably won't go through the form. And you might be able to capture some useful information along the way.

 

Dave Watts, Eidolon LLC

Dave Watts, Eidolon LLC
A
ACS LLCAuthor
Inspiring
September 20, 2018

I took another look at this and it appears to be the use of CFCONTENT.

I have a simple page with:

<cfheader name="Content-Disposition" value="attachment; filename=#downloadfilename#.exe" />

<cfcontent type="application/x-msdownload" file="#downloadlocation#\toolbox.exe" />

The code does function, the EXE is triggered for download, and yet I'm getting all these errors in the log file

Does anybody have any idea why?

WolfShade
WolfShade
Brainiac
September 20, 2018

We have been seeing this, too.  A lot.  I, also, have not been able to reconcile what is happening.  We have keyword searchable PDFs, and it is always a user clicking on a link to view a PDF that is triggering it.

V/r,

^ _ ^

Charlie Arehart
Charlie Arehart
Community Expert
January 2, 2020

Wondering if anybody ever found a solution to this? I am running ColdFusion 2016 Update 13 and I'm still seeing this issue.

 

I understand that it's not actually a 'real' failure and our site works just fine, but the problem is that it creates a lot of noise in the CF exception log file, making it difficult to weed out other real issues.

 

My guess is this might be search engines spidering the site and rapidly disconnecting before downloading the whole exe, as the exe is triggered on the loading of the page. My only option will be to change the page so there's a manual link to the exe rather than an automatic trigger.


Well, here's a tip, if you go that route: you may find it challenging to identify ALL spiders via the user agent header (which is what most would try to use for such detection). They may be too many and varied..Worse, some spiders will lie and present a legit user agent. 

 

Instead, if the page in question supports sessions, you could test for whether there are any incoming cookies (cgi.http_cookie is ""). Most spiders and automated agents don't bother to send one.

 

And while even a "real" user won't present a cookie on their very first visit, they will be given a. Cf session cookie after that first visit which they would then present on subsequent visits.

 

If both kinds of visitors "with no cookie" have no reason to receive that exe, this could solve things for you.

 

If not, let us know more about the exe. It's a curious thing to hear of a web page that downloads an exe automatically to all visitors. No need to explain, if this solves your problem.

 

And sure, ultimately, it would be great to solve this sort of problem more generically. And since I shared those other observations in Sept 2018 about other tomcat-based timeouts being the answer for others (not using the cf web server connector), I am still thinking that's a likely answer, but I saw your reply to me then saying you wanted to avoid fiddling with those, not knowing the pros/cons. 

/Charlie (troubleshooter, carehart. org)
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices