<div dir="ltr">I got a pagerduty alert from Datadog reporting that the HTTP monitor that's hitting <a href="https://wiki.jenkins-ci.org/display/jenkins/Git%20plugin">https://wiki.jenkins-ci.org/display/jenkins/Git%20plugin</a> is failing.<div><br></div><div>After a bit of digging, I discovered that the following command reports 403</div><div><br></div><div>$ wget --debug -O /dev/null '<a href="https://wiki.jenkins-ci.org/display/JENKINS/Home">https://wiki.jenkins-ci.org/display/JENKINS/Home</a>' <br></div><div><br></div><div>... while the following command does work</div><div><br></div><div>$ wget --debug --header 'User-Agent: xxx' -O /dev/null '<a href="https://wiki.jenkins-ci.org/display/JENKINS/Home">https://wiki.jenkins-ci.org/display/JENKINS/Home</a>'</div><div><br></div><div>That is, somebody in the middle is checking user-agent and refusing to serve wget based on User-Agent.</div><div><br></div><div>From inside the box that runs Confluence, if I hit confluence-cache layer directly, then wget works fine. So it has to be Apache that's terminating 443 on this box that's doing it.</div><div><br></div><div>I see that commit 675e4bdf added some scary looking user agent check, so this could be it, though that change was made back in January, so it's bit strange that it's backfiring now.</div><div><br></div><div>Since the site is functioning fine for regular users and we are all exhausted, I've snoozed the monitoring for a day. I'll leave it up to Tyler to decide if he wants to revert this change.</div></div>