HTTP DELETE requests "hanging" when accessing a cfc (but not cfm)

[gtheilman]

I have what appears to be a configuration problem with Coldfusion 10 running on a Windows server with IIS 7.5

I have a javascript function that is sending REST requests to the server.   I am able to make GET, POST,and PUT  HTTP  requests to a REST CFC with no problems.

However, when I send an HTTP  DELETE request to the CFC, the code within the delete function in the CFC executes (the delete query in the function runs), but then I don't get a status code sent back to the browser.   It's not that I get an error status code . . . I get NOTHING.   No status code is returned at all and the request process in the browser just sits there and waits.

Since the code within the function is working, I've tried "forcing" the return of a status code using cfheader.   It doesn't work.

However, if I take the query from the CFC and put it in a file with a CFM extension and call it using the HTTP DELETE method ...I get a 203 status code back right away indicating that the deletion was successful.

Running the same process on a local development server has no problems.   The DELETE request to the CFC works fine.   So, it must be something with the way the production server is configured.

So, the chain of events seems to be

1)  HTTP DELETE request is made to REST on the production server

2)  Coldfusion successfully finds the CFC and executes the code in the correct function

3)  The status code (failure, success, not found ... whatever) gets "lost" and is never sent back to the browser.

The main difference seems to be what extension is on the file name.   It works in a .CFM file but doesn't work when the same code is called from a .CFC file.

I've been banging my head against the desk for hours working on this and just don't know where to go from here (other than write some sort of kludge that uses PUT to execute a delete query).  And since the problem seems to be on my production server I'm very nervous about doing "trial and error" settings changes.

[WolfShade]

Not sure if this will help, or not, but have you tried CFFLUSH after the delete command?

^_^

[gtheilman]

Using CFFLUSH to push out the status code I "manually' generated with CFHEADER is not something I tried...but it's a good idea.

Unfortunately, it doesn't seem to work.   Whatever is preventing the status code from being sent back to the browser also seems to be blocking output from the function.     The code on the server-side is getting run...it just doesn't want to send anything to the browser.

Thanks for the suggestion.  I appreciate the help.

[Miguel-F]

Not sure if this will help either but have you specified any request restrictions in IIS?  In IIS go to your website and click on the Handler Mappings.  You should have one for '*.cfc', '*.cfm', etc.  Double-click your cfc handler '*.cfc' and it should open the Edit Script Map dialog.  That has a Request Restrictions... button on it.  Click that button and you get the Request Restrictions dialog.  Click on the Verbs tab and see how it is configured.  Compare that one to your cfm handler '*.cfm'.  Any differences?

[gtheilman]

I did glance at those and they looked the same.   I went back again after your suggestion and looked again.

They are identical. 

Mapping is set to "FILE AND FOLDER"

Verbs is set to "All Verbs"

Access is set to "Script"

While I was there, I tried a couple of changes to the cfchandler

1)  I unchecked "Invoke handler only if request is mapped to ..." .    That didn't seem to change the behavior.

2)  I unchecked "All verbs" and manually typed in "GET, POST, DELETE, PUT, OPTIONS, HEAD, TRACE, CONNECT".    Again, it didn't seem to change the way the the server was behaving.  The status code isn't being sent.

Thanks for the suggestion.   It was a good thought.

[Miguel-F]

Have you tried monitoring the traffic with something like Fiddler (or something similar)? 

What status codes/returns do you see?

[gtheilman]

I had been using Firebug, but I went ahead and installed Fiddler.

From Fiddler, the headers I'm seeing for a "successful" PUT operation look like this:

REQUEST

PUT https://pharmd.umc.edu/rest/txPlan/annotations/147 HTTP/1.1

Host: pharmd.umc.edu

Connection: keep-alive

Content-Length: 220

Origin: https://pharmd.umc.edu

X-Requested-With: XMLHttpRequest

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11

Content-Type: application/json; charset=UTF-8

Accept: application/json, text/javascript, */*; q=0.01

Referer: https://pharmd.umc.edu/shared/planannotator/txplan.cfm

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Cookie: CFID=8201; CFTOKEN=a4cdebf7d4c99692-5B49886A-B390-A5E8-149287AD9DCA816B; WT_FPC=id=172.17.69.130-1782833648.30246562:lv=1352379602938:ss=1352379364348; PSM_HEIGHT=855; PSM_WIDTH=1595; THEME=hot%2Dsneaks; PRECEPTOR_ID_COOKIE=37; PLUGIN=Google; JSESSIONID=5C5C1E24416CB73517984A5865B83CE6.cfusion; CFID=""; CFTOKEN=""; CFGLOBALS=urltoken%3DCFID%23%3D8201%26CFTOKEN%23%3Da4cdebf7d4c99692%2D5B49886A%2DB390%2DA5E8%2D149287AD9DCA816B%26jsessionid%23%3D5C5C1E24416CB73517984A5865B83CE6%2Ecfusion%23lastvisit%3D%7Bts%20%272012%2D11%2D21%2012%3A38%3A35%27%7D%23timecreated%3D%7Bts%20%272012%2D09%2D26%2004%3A31%3A24%27%7D%23hitcount%3D3968%23cftoken%3Db531776d00c0eb79%2DF744E306%2DD26A%2DD590%2DD6D2C0A8576DE8AE%23cfid%3D4593%23; ui-tabs-1=7; CFGLOBALS=urltoken%3DCFID%23%3D8201%26CFTOKEN%23%3Da4cdebf7d4c99692%2D5B49886A%2DB390%2DA5E8%2D149287AD9DCA816B%26jsessionid%23%3D5C5C1E24416CB73517984A5865B83CE6%2Ecfusion%23lastvisit%3D%7Bts%20%272012%2D11%2D21%2013%3A16%3A03%27%7D%23timecreated%3D%7Bts%20%272012%2D09%2D26%2004%3A31%3A24%27%7D%23hitcount%3D3972%23cftoken%3Db531776d00c0eb79%2DF744E306%2DD26A%2DD590%2DD6D2C0A8576DE8AE%23cfid%3D4593%23

{"text":"test edited","ranges":[{"start":"/div/div[68]","startOffset":15,"end":"/div/div[68]","endOffset":41}],"quote":"nificant benefit being

RESPONSE

HTTP/1.1 200 OK

Content-Length: 10

Content-Type: application/json

Server: Microsoft-IIS/7.5

Set-Cookie: CFGLOBALS=urltoken%3DCFID%23%3D8201%26CFTOKEN%23%3Da4cdebf7d4c99692%2D5B49886A%2DB390%2DA5E8%2D149287AD9DCA816B%26jsessionid%23%3D5C5C1E24416CB73517984A5865B83CE6%2Ecfusion%23lastvisit%3D%7Bts%20%272012%2D11%2D21%2013%3A16%3A08%27%7D%23timecreated%3D%7Bts%20%272012%2D09%2D26%2004%3A31%3A24%27%7D%23hitcount%3D3973%23cftoken%3Db531776d00c0eb79%2DF744E306%2DD26A%2DD590%2DD6D2C0A8576DE8AE%23cfid%3D4593%23; Domain=.umc.edu; Expires=Fri, 14-Nov-2042 19:16:08 GMT; Path=/

CF_TOMCAT_REUSE_THIS_CONNECTION: FALSE

X-Powered-By: ASP.NET

Access-Control-Allow-Origin: *

Date: Wed, 21 Nov 2012 19:16:08 GMT

{"id":147}

The headers for the unsuccessful DELETE request look like this:

REQUEST

DELETE https://pharmd.umc.edu/rest/txPlan/annotations/147 HTTP/1.1

Host: pharmd.umc.edu

Connection: keep-alive

Content-Length: 220

Origin: https://pharmd.umc.edu

X-Requested-With: XMLHttpRequest

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11

Content-Type: application/json; charset=UTF-8

Accept: application/json, text/javascript, */*; q=0.01

Referer: https://pharmd.umc.edu/shared/planannotator/txplan.cfm

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Cookie: CFID=8201; CFTOKEN=a4cdebf7d4c99692-5B49886A-B390-A5E8-149287AD9DCA816B; WT_FPC=id=172.17.69.130-1782833648.30246562:lv=1352379602938:ss=1352379364348; PSM_HEIGHT=855; PSM_WIDTH=1595; THEME=hot%2Dsneaks; PRECEPTOR_ID_COOKIE=37; PLUGIN=Google; JSESSIONID=5C5C1E24416CB73517984A5865B83CE6.cfusion; CFID=""; CFTOKEN=""; CFGLOBALS=urltoken%3DCFID%23%3D8201%26CFTOKEN%23%3Da4cdebf7d4c99692%2D5B49886A%2DB390%2DA5E8%2D149287AD9DCA816B%26jsessionid%23%3D5C5C1E24416CB73517984A5865B83CE6%2Ecfusion%23lastvisit%3D%7Bts%20%272012%2D11%2D21%2012%3A38%3A35%27%7D%23timecreated%3D%7Bts%20%272012%2D09%2D26%2004%3A31%3A24%27%7D%23hitcount%3D3968%23cftoken%3Db531776d00c0eb79%2DF744E306%2DD26A%2DD590%2DD6D2C0A8576DE8AE%23cfid%3D4593%23; ui-tabs-1=7; CFGLOBALS=urltoken%3DCFID%23%3D8201%26CFTOKEN%23%3Da4cdebf7d4c99692%2D5B49886A%2DB390%2DA5E8%2D149287AD9DCA816B%26jsessionid%23%3D5C5C1E24416CB73517984A5865B83CE6%2Ecfusion%23lastvisit%3D%7Bts%20%272012%2D11%2D21%2013%3A16%3A08%27%7D%23timecreated%3D%7Bts%20%272012%2D09%2D26%2004%3A31%3A24%27%7D%23hitcount%3D3973%23cftoken%3Db531776d00c0eb79%2DF744E306%2DD26A%2DD590%2DD6D2C0A8576DE8AE%23cfid%3D4593%23

{"text":"test edited","ranges":[{"start":"/div/div[68]","startOffset":15,"end":"/div/div[68]","endOffset":41}],"quote":"nificant benefit being sho","uri":"https://pharmd.umc.edu/shared/planannotator/txplan.cfm","id":147}

Then, of course, there is not Response header.

Is there something else I could be looking at that would be more helpful?

[Miguel-F]

Since this is happening when calling a cfc, what do you have the returnType set to in your cfc?  And what are you returning from it (if anything)?

Can you share your cfc's relevant code (including the function declaration)?

[gtheilman]

Since it's working on my local development machine, I wasn't thinking much about it being the code.   But perhaps there is something I'm missing....

PUT Request (works)

    <cffunction name="update" access="remote" produces="application/json"  returntype="any" httpmethod="PUT" restpath="{annotationid}">

              <cfargument name="annotationid"

                  required="true"

                  type="numeric"

                  restargsource="path"/>

        <cfset requestBody = toString( getHttpRequestData().content ) />

        <cfset DeserializedAnnotation =  DeserializeJSON(requestBody)>

        <cfset escapedJSON = Escape(requestBody)>

        <cfquery    name = "UpdateJSON"  dataSource = "xxxx" result="stResult" >

            UPDATE annotations

            SET  annotation =   '#escapedJSON#',

                        updated = Now(),

                         quote = '#DeserializedAnnotation.quote#',

                          text = '#DeserializedAnnotation.text#',

                          uri = '#DeserializedAnnotation.uri#'

            WHERE id = #annotationid#

        </cfquery>

        <cfoutput>

            <cfset struct1 = {} />

            <cfset struct1["id"] = "#DeserializedAnnotation.id#" />

        </cfoutput>

        <cfreturn struct1 >

    </cffunction>

DELETE Request (doesn't work on production server, but works on desktop development server)        

    <cffunction name="destroy" access="remote" produces="application/json"  returntype="any" httpmethod="DELETE" restpath="{annotationid}">

        <cfargument name="annotationid"

                    required="true"

                    type="numeric"

                    restargsource="path"/>

        <cfquery    name = "UpdateJSON"  dataSource = "xxx" result="stResult" >

            DELETE  FROM annotations

            WHERE id =  #annotationid#

        </cfquery>

    </cffunction>

[Miguel-F]

To be fair, I have not written any cfc's using the new CF10 attributes 'httpMethod', 'produces' or 'restpath'.  So if I am reading it correctly, you are specifying that the function produces JSON and has a returntype of any but you do not specify a cfreturn.  Have you played around with adding cfreturn and some value?  Or changing the returntype to "void" and just adding <cfreturn /> ?

Admittedly I am guessing at things here...

[gtheilman]

The code needs to be cleaned up.   It's the result of several hours of trial-and-error.

I'm afraid I've tried both "forcing" a cfreturn response and not sending any response using "void".  

In both cases, a status code is not being sent back to the browser.

That's the frustrating thing.  Even with my crappy code it works fine on my desktop development server.    There just seems to be something wrong with the way it's working on the production server.

I appreciate your help.

[Miguel-F]

Is anything being written to the logs?

[gtheilman]

The only thing I'm seeing in the various IIS and Coldfusion log files are the GET, POST and PUT HTTP methods.   The DELETE requests aren't showing up at all.

2012-11-21 20:46:46 172.17.99.8 GET /rest/txPlan/annotations limit=20&uri=https%3A%2F%2Fpharmd.umc.edu%2Fshared%2Fplanannotator%2Ftxplan.cfm 80 - 172.17.69.130 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:8.0.1)+Gecko/20100101+Firefox/8.0.1+Firefox/8.0.1 200 0 0 18505

2012-11-21 20:46:56 172.17.99.8 POST /rest/txPlan/annotations - 80 - 172.17.69.130 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:8.0.1)+Gecko/20100101+Firefox/8.0.1+Firefox/8.0.1 200 0 0 4513

2012-11-21 20:47:00 172.17.99.8 PUT /rest/txPlan/annotations/152 - 80 - 172.17.69.130 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:8.0.1)+Gecko/20100101+Firefox/8.0.1+Firefox/8.0.1 200 0 0 2406

[Charlie Arehart]

Well that’s interesting if you don’t see any indication of the delete request in the IIS logs (while you do see it for the other methods).

So here are a couple of thoughts.

- are both your local dev and the remote prod server the same release of CF 10 (same updater level)? You can check in the CF Admin “system information” page (the “I” icon in the top right corner), where it will say 10,0,x where the x will reflect what updater has been added. There could be differences between your two machines that may have an effect

- since you say there is no request logged in the IIS logs (on prod), that makes me think that that the app pool is crashing when the request is made. Have you applied updater 4 or 5 in prod? Those each address issues that could lead to the IIS app pool crashing. Have you looked in the Windows Event Viewer to perhaps confirm?

- I’ll assume that CF is not itself crashing on that delete request. Are you doing anything to confirm that? I realize you say you see some output that you are creating, but it could do that before CF might crash, I suppose. Just worth checking.

- finally, you mention using IIS on the prod machine. What about on Dev? You don’t say, and while we could assume you have it setup also as IIS, you could also be using the built-in web server (port 8500). If you are using IIS on Dev, is it also IIS 7? And might it be in IIS 6 compatibility mode, where the prod box may not be?

Hope some of that may help.

/charlie

[gtheilman]

Thanks for your thoughts, Charlie.   They have given me some directions to explore.

The local dev was actually a couple of patches behind the prod.   I went ahead and installed updater 4 and 5 on the prod.   While it was a good thing to do, it didn't resolve the problem.

I started looking in the Windows Event Log and found this:

A worker process '4988' serving application pool 'DefaultAppPool' failed to stop a listener channel for protocol 'http' in the allotted time.  The data field contains the error number.

I checked Microsoft's website and they suggested restarting the app pool and WAS.   I did that, but it didn't resolve the problem.   I'm not sure where to go further with this.

CF Server isn't crashing, at least not in a way I can tell.

The last point is the one I think might be part of the problem.    While I'm running IIS 7.5 on the prod, I'm running the built-in web server on dev.   Which is making me think it is something to do with IIS 7.5 and how it is configured.   Is it possible to run both the built-in webserver (on 8500) and IIS (on 80) at the same time without totally screwing up my prod?   I'm thinking maybe I could route the DELETE requests through 8500 while running everything else through IIS.

Again, thanks for your help.

Gary

[gtheilman]

Here's something else I found after enabling the Failed Requests log.  It came up as a "Warning".

ModuleName	IsapiModule
Notification	128
HttpStatus	405
HttpReason	Method Not Allowed
HttpSubStatus	0
ErrorCode	0
ConfigExceptionInfo
Notification	EXECUTE_REQUEST_HANDLER
ErrorCode	The operation completed successfully. (0x0)

I'm nots sure if this is related, but it might be something.

[Miguel-F]

Charlie the other odd thing here is that the request actually makes it to the cfc and the cfc executes its code successfully. The only missing piece as I understand it is that no return value is sent.

Right Gary? Although the only difference between the environments does seem to be IIS.

[gtheilman]

That's correct.  It seems to be something blocking it after the CFC code is executed but before any response from the CFC can get to the browser.

Again, it's only with DELETE calls (PUT, GET, and POST all work fine).

It's also only with CFCs (*.cfm files work fine with DELETE).

I'm just stumped.

[Miguel-F]

Another thought, (I can't verify right now) are those request restrictions available to the isapimodule itself in IIS? Similar to my previous post for the cfc handler.

(Sent from mobile device)

[gtheilman]

Looking at ISAPI-DLL it has "ALL VERBS" checked.  

There are other 'IsapiModule' handlers.   They mostly seem to have "ALL VERBS" checked by default.  There's a few (HttpRemotingHandlerFactory-rem-ISAPI-2.0) that have a subset of VERBS checked, but I don't think it has anything to do with CF.

[e.esquivel]

Did you solve your trouble? I have exactly the same issue here.

[gdtheilman]

Never got it to work.   

The only reason I was using REST at that time was because a 3rd party plugin required it.   I ended up rewriting part of the plugin so it would make use of the HTTP METHODS that were working.

Other than that one time, I've not used the REST function in ColdFusion.   I just call CFCs the way I did before upgrading to CF10.

[e.esquivel]

After some hours (close to days) we finally succeeded. After more test to understand .... we still do not really understand.

Symptoms

The HTTP request with a DELETE verb is pending then canceled when calling a REST service.

Configuration

Coldfusion 10

IIS (7.5,8)

Windows 7, Windows server 2012 R2

Debuging

On colfusion a REST service is setup and it works for PUT,POST,GET verbs.

The REST service in our case was call via EXTJS 4
On a development server without IIS it works.

• Client Side, we changed the call to a POST instead of a DELETE and we had the same symptoms with pending, We try also to solve this issue.
• Server side on IIS, there are some discussions with Webdav and handlers that have been tested without success. Installing Webdav the server send an error message, that was better than the pending but when we remove webdav Coldfusion return nothing. We try to change the order of the modules and handlers, to add DELETE for all handlers, change the CFC handler settings.
  
• I found that the request goes to Colfusion looking some Coldfusion logs.
  
• On coldfusion I read the documentation concerning Tomcat, Jakarta. I added IUSR to the folder virtual path folder CFIDE and Jakarta

Solution

Adding "struct body" to the arguments of the method link to delete make it works .

remote struct function myMethodUsedToDelete(required numeric myArgument restargsource="Path", struct body) httpmethod="delete" restpath="{myArgument }" produces="application/json"  returnformat="json" { }

References

I cold not find usefull links or discussions so far.

Nothing helpfull on the documentation.

http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSe61e35da8d318518-5719eac51353e6bb244-7fe6.h...

[Charlie Arehart]

@e, I know you said earlier in the thread (Nov 2012) that you had confirmed that your CF10 was updated (then, and I assume now to 12 or 13).

But I don’t see that anyone here ever talked about ensuring that your connector (IIS to CF connector) was updated. It’s a common problem for folks to apply CF updates but NOT notice they need to update the connector (after certain of the CF10 updates). Often, Adobe has fixed a bug that simply won’t take effect until you do update the connector.

I talk more about this matter (why to do it, how to, how to check if you have) in this blog entry:

http://www.carehart.org/blog/client/index.cfm/2013/9/13/why_you_must_update_cf10_webserver_connector

Hope that’s helpful.

/charlie

[e.esquivel]

Thanks Charlie,

What I did after your remarks.

I checked if the CF10 was up to date. It was not.
First, the installation I used was from march 2014 and I was assuming the installation was updated.

I spend time (too much) to update it, this is what I did.

• I created a folder C:\ColdFusion10\cfusion\hf-updates
• I installed the the madatory update http://helpx.adobe.com/coldfusion/kb/coldfusion-10-mandatory-update.html
  Running the command line in as administrator
  with a command line like so C:\ColdFusion10\jre\bin\java.exe -jar C:\ColdFusion10\cfusion\hf-updates\cf10_mdt_updt.jar
• Add the proxy setting to the JVM config from the adminsitrator page.
  add after -Dcoldfusion.home={application.home} :
  -Dhttp.proxyHost=<yourproxy> -Dhttp.proxyPort=<yourport>
• Then I used the administrator page to do the updates
  You can install just the last on (13) in my case in march 2014 it include the previous ones
  CF is now 10,0,12,287689
• Then I checked the IIS C:\ColdFusion10\config\wsconfig\1\isapi_redirect.dll
  It was modified in march 2012
  I stopped IIS service and CF service
  and I did C:\ColdFusion10\cfusion\bin\connectors\Upgrade_all_connectors.bat
  then I did C:\ColdFusion10\cfusion\bin\connectors\IIS_connector.bat
  I restarted all the services
  I checked the date of C:\ColdFusion10\config\wsconfig\1\isapi_redirect.dll
  it was ‎Saturday, ‎November ‎2, ‎2013, ‏‎2:12:36 PM
  
  

After all that.

Same symptoms occured. Same solution worked.

We will do a turnaround with the other troubles not solved we had with a POST.

reading the updates I saw that some could fix character encoding trouble we had.

Usefull links

http://blogs.coldfusion.com/post.cfm/coldfusion-hotfix-installation-guide

http://www.carehart.org/blog/client/index.cfm/2013/9/13/why_you_must_update_cf10_webserver_connector

Not so usefull but necessary links

http://www.adobe.com/support/coldfusion/downloads_updates.html

http://help.adobe.com/en_US/ColdFusion/10.0/Admin/WSe61e35da8d318518-33adffe0134c60cd31c-7ffe.html