Strange HTTP probe with .cfm files.

[inetu]

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

[Paul Pinto]

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.

[inetu]

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.

[Paul Pinto]

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.

[inetu]

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

[Sean Merrow · Accepted solution]

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

[Paul Pinto]

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.

[Sean Merrow]

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:

1. Get the output of show probe BPC_SERVICE_HTTP detail
2. Start a network capture using SPAN on the switch's Tengig port to the ACE
3. Let a couple probes fail
4. Stop the SPAN
5. Get a second output of show probe BPC_SERVICE_HTTP detail

Otherwise, glad to hear its working for you after changing it to SUCCESS.

Thanks,

Sean

[Paul Pinto]

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

[inetu]

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