04-01-2010 02:02 PM
Hey All,
I setup an http probe that checks a .cfm page for a keyword. according to the documentation there needs to be a content-length in the header for this to be parsed correctly. For some reason this .cfm page does not send the content-length. The developer manually told coldfusion to put the content-length in the header and I can see that the header now has the content-length. The probe is still failing with "Unrecognized or invalid response" If i put a test html page with a keyword, it parses it correctly and passes. If i change the keyword it fails as expected. Has anyone had any issues with the headers of coldfusion? There is no compression on the server side. Below is the probe.
probe http KEYWORD
interval 15
passdetect interval 30
request method get url /index.cfm
open 2
expect regex "go"
Any help or suggestion would be much appreciated.
Regards,
Christian
Solved! Go to Solution.
04-04-2010 09:58 AM
Hey Christian and Paul,
Actually, when using expect regex, you don't need the expect status. I alerted the documentation team about this and they have updated the documents with the following note:
Note If you do not configure an expected status code, any response from the server is marked as failed. However, if you configure the expect regex command without configuring a status code, the probe will pass if the regular expression response string is present.
Christian,
You mention that you see the error message Unrecognized or invalid response, even with the content-length header added. Is this the same error message you got before your app team added the header? If so, then I might suspect that the ACE doesn't like the format they used. The header should look like this:
Content-Length:
This is per RFC2616 and can be found at section 14.13 here. Note that the C and the L are uppercase, the header name is immediately followed by a colon, and there is a spece between the colon and the value.
I would recommend confirming that the header matches this description in a network capture. If it does match, then I would like to see the capture, if possible.
Thanks and I hope this helps,
Sean
04-02-2010 05:09 AM
Hi Christian,
You are required to have the "expect status" in the probe configuration.(200 should be fine. If not check you are not recieving something like 304.)
So you should have the following:
probe http KEYWORD
interval 15
passdetect interval 30
request method get url /index.cfm
expect status 200 200<<<<<<<<
open 2
expect regex "go"
Hope this helps. Please rate if this resolves your problem.
Paul.
04-02-2010 09:22 AM
Hi Paul,
Thanks for the reply. I tried the expect status and i still am getting the same "Last disconnect err : Unrecognized or invalid response" error. I am not even seeing a status code in the details of the probe.
Last status code : 0
I would think I would get the last status code. I dont see any of these errors with a straight html file with a keyword.
04-03-2010 02:07 AM
Hi Christian,
What happens if you add expect status 0 999?
Also, have you tried retrieving the url with FireFox and FireBug and confirmed your responses, is the page available, are you recieving what you expect?
Another thing to check for Christian. It may be to do with the number of bytes.I had an issue with checking for regex in http probe. It was the length of the content. We had OK and were checking for this with probe and always failed. Changed to SUCCESS, checked for this and functioned as expected.
So if you have this currently:
probe http KEYWORD
interval 15
passdetect interval 30
request method get url /index.cfm
expect status 200 200
open 2
expect regex "go"
Modify your index.cfm to provide other output or check for some other content on the page and then something like:
probe http KEYWORD
interval 15
passdetect interval 30
request method get url /index.cfm
expect status 200 200
open 2
expect regex "success"
Hope this helps.
Paul.
04-28-2010 12:30 PM
Hi Paul,
It didnt matter what I threw at this probe, I could not get the probe to see the headers from the .cfm files. My workaround was tu use a custom HTTP probe which did the trick. Thanks for your help.
Regards,
Christian
04-04-2010 09:58 AM
Hey Christian and Paul,
Actually, when using expect regex, you don't need the expect status. I alerted the documentation team about this and they have updated the documents with the following note:
Note If you do not configure an expected status code, any response from the server is marked as failed. However, if you configure the expect regex command without configuring a status code, the probe will pass if the regular expression response string is present.
Christian,
You mention that you see the error message Unrecognized or invalid response, even with the content-length header added. Is this the same error message you got before your app team added the header? If so, then I might suspect that the ACE doesn't like the format they used. The header should look like this:
Content-Length:
This is per RFC2616 and can be found at section 14.13 here. Note that the C and the L are uppercase, the header name is immediately followed by a colon, and there is a spece between the colon and the value.
I would recommend confirming that the header matches this description in a network capture. If it does match, then I would like to see the capture, if possible.
Thanks and I hope this helps,
Sean
04-05-2010 05:04 AM
Hi Sean,
Thanks for that feedback.
Any idea why our probe then did not function when configured to check for "OK". Our Content-Length is of the correct format (IIS). The script on the server is for SAP application with the Web/App collapsed into a single server (multiple instances). The script on the server checks the App service and database availability. If all is well returns page on /Probe.aspx with SUCCESS and if either fails returns page on /Probe.aspx with FAILED. Originally the successful one returned OK on the page.
Original probe failed always:
probe http BPC_SERVICE_HTTP
port 88
interval 10
passdetect interval 15
passdetect count 2
request method get url /Probe.aspx
expect status 200 200
header User-Agent header-value "Cisco-ACE-Probe"
expect regex "OK"
Changed the script to ouput SUCCESS and changed probe accordingly and no problem:
probe http BPC_SERVICE_HTTP
port 88
interval 10
passdetect interval 15
passdetect count 2
request method get url /Probe.aspx
expect status 200 200
header User-Agent header-value "Cisco-ACE-Probe"
expect regex "SUCCESS"
Any idea's?
Thanks again Sean.
Paul.
04-05-2010 05:58 AM
Hi Paul,
I just tested a probe with the same config and checking for OK, and it is working for me on A2(3.0).
With the only difference between the two probe configurations being OK versus SUCCESS, I cannot explain why it didn't work without seeing a network capture. If you want to investigate further, I would recommend the following:
Otherwise, glad to hear its working for you after changing it to SUCCESS.
Thanks,
Sean
04-06-2010 04:46 AM
Hi Sean,
Thanks for the feedback. The one differance then is we have A2(1.5a). Don't know if there may and an issue there. Also the site is ASP.NET, not sure there either.
We were under a bit of a time constraint, thus changing the output.
We are in the process of upgrading customer to ANM 3.1 and therfore also recommending upgrading to A2(3.0). So hopefully if the issue was with A2(1.5a) we would then not experience this again.
Thanks again Sean
Paul
04-28-2010 12:33 PM
Hi Sean,
Thanks for you help. I ended up using a custom HTTP probe to remedy the issue. I could not get the built in probe to work.
Regards,
-Christian
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide