Special check_http variation

[Subhendu Ghosh]

Following up on my own posts ;)

you could have wget run in debug mode, regex the content-length, verify 
the size of the saved image matches the content length

----sample wget output (response...)
HTTP request sent, awaiting response... HTTP/1.0 200 OK
Connection: Keep-alive
Content-Length: 11213
Content-Type: image/jpeg


Registered fd 3 for persistent reuse.
Length: 11,213 [image/jpeg]

100%[====================================>] 11,213        25.47K/s    ETA 
00:00

13:11:25 (25.47 KB/s) - `image.4' saved [11213/11213]

---end sample---


For the check_http patch - probably needs to be done sooner than later ;)

modify the while loop (line 626) such that the STATUS_LINE and HEADER
is created using the loop rather than parsing the received data.

Would allow more checks against content-type and content-length that some
folks have asked for.

Multipart-pages are not affected as we currently don't parse and retrieve 
all sub-parts.

-sg

On Wed, 14 May 2003, Subhendu Ghosh wrote:

> The url is returning the header below followed by the actual image(s).  
> However, on occasion, it has also returned a different content-type.
> "application/octet-stream (Binary Executable)"
> 
> HTTP/1.0 200 OK
> Connection: Keep-alive
> Content-Length: 25699
> Content-Type: image/jpeg
> 
> 
> The check_http code does not end until the receive buffer is empty - i.e. 
> full page is received.  With the motion-jpeg stream, the server starts to 
> stream the sequence of jpeg images with no end.  So the receive buffer 
> always has data.
> 
> The browsers treat the server differently because of the content-type.  
> They honor the content-type info and read the only the "content-length" 
> worth of data.
> 
> The work-around for now would be to write a shell script around 
> 
> "wget -q http://195.30.64.242/cgi-bin/image"
> delete the saved image
> check the response code from wget == 0
> 
> Long term patch for check_http would be to parse the initial couple of 
> receive buffers to determine the "content-length" and close the connection 
> after reading "content-length" worth of data.  This has implications for 
> multi-part pages (pages with images) that needs to be explored.
> 
> 
> -sg
> 
> 
> On 14 May 2003, Matthias Eichler wrote:
> 
> > Hi List,
> > 
> > we have some special software running which gives some jpeg and
> > motion-jpeg output of some videostream. Unfortunately this software
> > is not very stable, so I wanted to monitor it with check_http.
> > 
> > The image can be downloaded via http://195.30.64.242/cgi-bin/image.
> > The motion jpeg stream can be get as an octet-stream via
> > http://195.30.64.242/cgi-bin/video.
> > 
> > The command "./check_http -I 195.30.64.242" brings the correct 404 page,
> > because there is no directory index.
> > The command "./check_http -I 195.30.64.242 -u /cgi-bin/image" brings a
> > timeout after 10 seconds, although I can telnet to that address and can
> > download the image via "GET /cgi-bin/image".
> > 
> > Can anybody give us some hint?!?
> > Would be great and feel free to try the URL...
> > 
> > Thanks,
> > 
> > Matthias Eichler
> > 
> > 
> 
> 

-- 




-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
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