Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Not sure if this will help, or not, but have you tried CFFLUSH after the delete command?
^_^
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Have you tried monitoring the traffic with something like Fiddler (or something similar)?
What status codes/returns do you see?
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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)?
Copy link to clipboard
Copied
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>
Copy link to clipboard
Copied
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...
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Is anything being written to the logs?
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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)
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Did you solve your trouble? I have exactly the same issue here.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
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.
Copy link to clipboard
Copied
@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
Copy link to clipboard
Copied
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.
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