check_http timeout due to non-close with chunked encoding
Daniel Beardsmore <[email protected]> Fri, 16 Feb 2018 10:15:54 +0000
| Newsgroups | gmane.network.nagios.devel |
|---|---|
| Message-ID | <0278F52E2C71ED4E92D9DAC979200D2902B81833FD04__32684.671766083$1518779494$gmane$org@TRUSTSERVER.TrustNetworks.local> |
--_000_0278F52E2C71ED4E92D9DAC979200D2902B81833FD04TRUSTSERVER_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Since this is check_http v2.1.1 from Debian 8, and may now be resolved, but=
I'll report this anyway just in case it's enough of an edge case to have n=
ot yet been detected and reported.
We have a server application (F-Secure Policy Manager Server for Linux) tha=
t in its latest version (13) uses chunked transfer encoding and does not cl=
ose the connection after sending the final chunk. (Testing the non-secure p=
ort with telnet shows that it sits and waits for the client to close the co=
nnection.)
check_http requires the server to close the connection after the final chun=
k is set, and when the HTTP(S) server does not close the connection, check_=
https times out the connection.
The bigger problem is that verbose mode (-v) pretends that no data was rece=
ived. It does not write output in real time, and it doesn't report even the=
headers unless the connection was successful. What -v should show, is ever=
ything received up to the point that the connection timed out. Instead, it =
makes it look like the connection is being blocked somewhere and that nothi=
ng was received, not even the headers.
For HTTP, I can use telnet to probe the output directly (testing in links f=
rom the Nagios server showed that it was not a firewall problem -- I could =
see that it was Nagios-specific somehow). For HTTPS, I cannot do that. Fort=
unately, this server has both HTTP and HTTPS modes, making testing easy. If=
it was HTTPS-only, I'd have to use something like openssl client to run th=
e tests, something that is possibly less well-known.
Granted, it's a real edge case, but I thought I'd mention it anyway in case=
anything can be done to help other admins with similar situations (either =
servers that leave the connection open, or situations where connections han=
g half-way through, which I've seen before due to networking problems.)
Regards
Daniel.
--_000_0278F52E2C71ED4E92D9DAC979200D2902B81833FD04TRUSTSERVER_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoNormalCxSpFirst, li.MsoNormalCxSpFirst, div.MsoNormalCxSpFirst
{mso-style-type:export-only;
margin:0cm;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoNormalCxSpMiddle, li.MsoNormalCxSpMiddle, div.MsoNormalCxSpMiddle
{mso-style-type:export-only;
margin:0cm;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoNormalCxSpLast, li.MsoNormalCxSpLast, div.MsoNormalCxSpLast
{mso-style-type:export-only;
margin:0cm;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle15
{mso-style-type:personal;
font-family:"Arial",sans-serif;
color:#00007F;}
span.EmailStyle16
{mso-style-type:personal-compose;
font-family:"Arial",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-GB link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormalCxSpFirst><span s=
tyle=3D'font-size:10.0pt;font-family:"Arial",sans-serif'>Since this is chec=
k_http v2.1.1 from Debian 8, and may now be resolved, but I’ll report=
this anyway just in case it’s enough of an edge case to have not yet=
been detected and reported.<o:p></o:p></span></p><p class=3DMsoNormalCxSpM=
iddle><span style=3D'font-size:10.0pt;font-family:"Arial",sans-serif'><o:p>=
</o:p></span></p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-s=
ize:10.0pt;font-family:"Arial",sans-serif'><o:p> </o:p></span></p><p c=
lass=3DMsoNormalCxSpMiddle><span style=3D'font-size:10.0pt;font-family:"Ari=
al",sans-serif'>We have a server application (F-Secure Policy Manager Serve=
r for Linux) that in its latest version (13) uses chunked transfer encoding=
and does not close the connection after sending the final chunk. (Testing =
the non-secure port with telnet shows that it sits and waits for the client=
to close the connection.)<o:p></o:p></span></p><p class=3DMsoNormalCxSpMid=
dle><span style=3D'font-size:10.0pt;font-family:"Arial",sans-serif'><o:p>&n=
bsp;</o:p></span></p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-siz=
e:10.0pt;font-family:"Arial",sans-serif'>check_http requires the server to =
close the connection after the final chunk is set, and when the HTTP(S) ser=
ver does not close the connection, check_https times out the connection.<o:=
p></o:p></span></p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-size:=
10.0pt;font-family:"Arial",sans-serif'><o:p> </o:p></span></p><p class=
=3DMsoNormalCxSpMiddle><span style=3D'font-size:10.0pt;font-family:"Arial",=
sans-serif'>The bigger problem is that verbose mode (-v) pretends that no d=
ata was received. It does not write output in real time, and it doesn’=
;t report even the headers unless the connection was successful. What -v sh=
ould show, is everything received up to the point that the connection timed=
out. Instead, it makes it look like the connection is being blocked somewh=
ere and that nothing was received, not even the headers.<o:p></o:p></span><=
/p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-size:10.0pt;font-fami=
ly:"Arial",sans-serif'><o:p> </o:p></span></p><p class=3DMsoNormalCxSp=
Middle><span style=3D'font-size:10.0pt;font-family:"Arial",sans-serif'>For =
HTTP, I can use telnet to probe the output directly (testing in links from =
the Nagios server showed that it was not a firewall problem -- I could see =
that it was Nagios-specific somehow). For HTTPS, I cannot do that. Fortunat=
ely, this server has both HTTP and HTTPS modes, making testing easy. If it =
was HTTPS-only, I’d have to use something like openssl client to run =
the tests, something that is possibly less well-known.<o:p></o:p></span></p=
><p class=3DMsoNormalCxSpMiddle><span style=3D'font-size:10.0pt;font-family=
:"Arial",sans-serif'><o:p> </o:p></span></p><p class=3DMsoNormalCxSpMi=
ddle><span style=3D'font-size:10.0pt;font-family:"Arial",sans-serif'><o:p>&=
nbsp;</o:p></span></p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-si=
ze:10.0pt;font-family:"Arial",sans-serif'>Granted, it’s a real edge c=
ase, but I thought I’d mention it anyway in case anything can be done=
to help other admins with similar situations (either servers that leave th=
e connection open, or situations where connections hang half-way through, w=
hich I’ve seen before due to networking problems.)<o:p></o:p></span><=
/p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-size:10.0pt;font-fami=
ly:"Arial",sans-serif'><o:p> </o:p></span></p><p class=3DMsoNormalCxSp=
Middle><span style=3D'font-size:10.0pt;font-family:"Arial",sans-serif'><o:p=
> </o:p></span></p><p class=3DMsoNormalCxSpMiddle><span style=3D'font-=
size:10.0pt;font-family:"Arial",sans-serif'>Regards<o:p></o:p></span></p><p=
class=3DMsoNormalCxSpMiddle><span style=3D'font-size:10.0pt;font-family:"A=
rial",sans-serif'><o:p> </o:p></span></p><p class=3DMsoNormalCxSpLast>=
<span style=3D'font-size:10.0pt;font-family:"Arial",sans-serif'>Daniel.<o:p=
></o:p></span></p></div></body></html>=
--_000_0278F52E2C71ED4E92D9DAC979200D2902B81833FD04TRUSTSERVER_--