Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Aditya 24 posts 128 karma points
    Oct 12, 2016 @ 05:02

    Healthcheck Click-Jacking protection fails with an odd error.

    Edit - I answered my own question, see here ->

    it's a bug.

    I'll leave the question up just in case someone else sees this.

    I'm running the latest version of Umbraco on Azure. I have a rule in my web.config that redirects all traffic to HTTPS.

    When I run the healthcheck, everything passes except for the click-jacking protection.

    Here's the error I get

    "Error pinging the URL http://sitename:443 - 'The underlying connection was closed: An unexpected error occurred on a receive.'"

    I know that http://sitename:443 returns nothing - I've tried with curl -i and get an empty reply. This is how it should be. Azure will not serve HTTP over 443.

    My question is, why is Umbraco pinging http in the first place? It should be pinging https, right?

  • Sebastiaan Janssen 5010 posts 15285 karma points MVP admin hq
    Oct 12, 2016 @ 07:24
    Sebastiaan Janssen

    This is a bug fixed in the upcoming version 7.5.4 -

  • Eric Schrepel 158 posts 223 karma points
    Jul 01, 2019 @ 20:26
    Eric Schrepel

    I'm getting the same problem in v8.0.2, was this resolved? ("Error pinging the URL https://...") for all three click-jacking, MIME sniffing, cookie hijacking checks. Running an intranet site on IIS, have set umbracoApplicationUrl="" in web.routing, have UseHttps = true, etc. Get the same error whether we have http->https rewrite rules in place or not. Wondering if this relates to the every-5-minute KeepAlive log errors we get also.

  • Gary 80 posts 377 karma points
    Aug 21, 2019 @ 13:03

    Hi Eric,

    We get same error in 7.12.4, did you find what the issue was?

    Kind Regards,

    Gary Henshall

  • Eric Schrepel 158 posts 223 karma points
    Aug 21, 2019 @ 16:23
    Eric Schrepel

    Never did get it resolved (still an issue in 8.1.1).

    Because our site is a low-traffic intranet, we decided to ignore the keepalive issue, and instead set IIS application pool parameters to disable Rapid-Fail Protection (per this article:, and to adjust a few other settings so that the application pool basically never recycles, just stays alive.

    Still annoying to have those warnings pop up in the logs every 5 minutes, but changing the IIS settings at least mimics the same "keep alive" function.

Please Sign in or register to post replies

Write your reply to: