Jump to content
Welcome to our new Citrix community!

HTTPS-ECV Monitor failing on cshtml page

Recommended Posts

I am trying to create a simple custom https-ecv monitor.  Our statuspage is built using cshtml.  If I do a simple GET /serverstatus with no string it works.  However if i put the string in I get the "failure - pattern not found in response.  


if i do a curl -v -k https://<siteurl>/serverstatus/ from the shell I see my string in the results but the monitor doesnt want to see it


What am i missing?

Link to comment
Share on other sites

1) the ecv monitor is a simple string return and is case sensitive.

Be sure the string you are looking for always appears in the response AND matches the case of the string you are searching. No regex/pattern matching supported by this monitor.

2) As a monitor it only parses output it the first 24 K bytes of the response (I thought later versions would go up to 60K, but can find a confirmation of this number.); so if the string you are looking for is much later in the response, the monitor won't see it.  Try a simpler test by looking at an earlier response string to see if the size of the response relative to the string you are looking for is the problem.


If you still have problems:

1) if your services are https, be sure the secure flag is enabled (and create a new blank monitor of type http-ecv with secure on, instead of copying the pre-built https monitor...just in case).

2) Try simplifying the string or checking an earlier string.

3) Try switching to a regular http/s monitor with a response code check instead...if this fails too, then you should run a trace and see if there is an issue with the monitor snip to service communication.



Link to comment
Share on other sites

Thanks for the reply.

1) I copied an pasted the text from the page so the string is exactly the same

2) the page is just a simple status page only no frill no nothing.  Only a few lines of text.... but I will check that out.


As i said this monitor works when i take the string out so pretty sure there is nothing wrong with the https.  I did build it from scratch.  I am testing right now with a one word string can't get much simpler than that and I am already doing a basic monitor that is working just fine.  The text im looking for is at the top of the page but I am going to try strip it down even more.  I'll say this I have worked with Kemp load balancers as well and never had a problem doing a string search on a pages that we more advanced than this one.  Not sure why VPX is having this issue.

Link to comment
Share on other sites

Are you sure you are using the right field?  Check from CLI to see if you have aberrant spaces in the string that are being looked for as well?  You can see if there are quotes around the test string.


Usually this monitor works very well, so either we have a wrong parameter or a bug was found on this version.  If you can share the cli of your monitor or the gui screenshot just to make sure there's not an unexpected value  or incorrect parameter.

Link to comment
Share on other sites

ECV monitors aren't hard, so yes, this should be working. You could always do a trace to see what's happening to this particular monitor vs an HTTP monitor.

I would put the -recv string in quotes (but it shouldn't matter in this context.)


First though, usually when we do a monitor problem its to a specific page, such as "get /serverstatus.htm"  and not some directory "get /serverstatus/".

If you were to put this in a browser, 1) do you get the response string you are looking for, but 2) when using a header viewer is the response string generated for this request or for some dependent object such as the call to /serverstatus/ actually retrievies other pages/objects and the "response" you are searching for is on one of these other requests...as that would cause the monitor to fail.



Otherwise if that is indeed the request you are supposed to make, I'm baffled too. So the only other things I'm thinking of are:

- possible bug on this version, but some testing should rule that out

- OR an issue with the https request such as 1) improper ssl profile/secure settings than what the service is expecting or 2) needing a host header for the https request.


So my thoughts to diagnose this,

1) run a trace to see what is happening to this probe

2) and compare a regular http-ecv vs https-ecv (if they both fail), then compare a regular http/https monitor vs the -ecv monitor.  This may help determine if bug or an issue specific with the ecv behavior (or just the https-ecv behavior) or something app specific.  You could also compare the monitor against a simpler web page to see if it works for other apps but not this one.

3) Depending on if http-ecv works; but https-ecv fails, then modify the https-ecv parameters such as ssl profile OR add a custom host header to the monitor (info below).

If the http/http-ecv works but the secure versions fail then we have a different set of info to work from...


Details on above:

So to test the non-secure versions of the monitor, your services would have to listen on http and https. YOu would then need a version of the monitor without the secure flag enabled and a destination port 80 specified OR create an http version of the service for the http monitor testing.


For the custom header teset, the thinking is that normally the monitor inserts a host header with the service IP, but in the case of the https monitor you may be getting an issue with the host header not matching the info in the destination service's cert (shouldn't...but its worth trying).

You can configure the monitor to insert a custom header (by editing the monitor in the GUI or a set lb monitor command with the parameter):


-customHeaders "Host:service.example.com\r\n"   Where the host is valid for the destination service.


The SSL PROFILE can be adjusted if the default probe's ssl settings are not meeting the strictness settings of the service's SSL connection (or if it needs to be more relaxed); maybe there is an ssl protocol or cipher disconnect between the probe and the service destination.  (But at this point a trace could also give us some info as it shouldn't be this hard.)



Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...