check_http fails for two Sprint sites

[Frank Bulk - iName.com]

FYI: Sprint did something this morning such that those sites are now
checking cleanly with check_http.

Frank

________________________________________
From: Frank Bulk [frnkblk at iname.com]
Sent: Friday, February 24, 2012 8:27 AM
To: 'Paul Dubuc'; 'Nagios Users List'
Subject: RE: [Nagios-users] check_http fails for two Sprint sites

Yes, I did -- no go.  You can test it yourself -- there's nothing special
about where I'm testing it from. =)

It's clear that check_http is choking on it, and I suspect it's because it
redirects to a secure version of the site.

Frank

-----Original Message-----
From: Paul Dubuc [mailto:work at paul.dubuc.org]
Sent: Friday, February 24, 2012 8:26 AM
To: frnkblk at iname.com; Nagios Users List
Subject: Re: [Nagios-users] check_http fails for two Sprint sites

Frank Bulk wrote:
> Starting this morning two IPv6 sites, www.sprint.net and www.sprintv6.net
> failed to pass check_http.  What's strange is that the v4 version of
> www.sprint.net also fails.
>
> I see that there are 302's (redirection) to the secure version of the
site,
> but using the '-f follow' command doesn't help, either.  It seems that if
> the site one being is redirected to is secure that the check command
fails.
>

Did you try any of the other options for -f, like '-f sticky' or '-f
stickyport'?



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null