[Nagiosplug-devel] [ nagiosplug-Bugs-3593304 ] check_http injecting garbage into content, breaking --string

SourceForge.net noreply at sourceforge.net
Fri Dec 7 10:44:23 CET 2012 

Bugs item #3593304, was opened at 2012-12-06 12:48
Message generated for change (Settings changed) made by hweiss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3593304&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General plugin execution
Group: v1.4.14
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Whitlock (jwhitlock)
>Assigned to: Holger Weiss (hweiss)
Summary: check_http injecting garbage into content, breaking --string

Initial Comment:
Plugin Version (-V output):  check_http v1.4.16-61-g1845c (nagios-plugins 1.4.16)
Plugin Name:  check_http
Plugin Commandline showing issues: ./check_http -H 'www.consumeraffairs.com' -u '/' -v | head -n 20
Operating System: OS X 10.8.2, Ubuntu 12.04.1 LTS
Architecture: x86_64
Compiler: gcc 4.2.1, ubuntu package

When running check_http against our server, it appears to inject garbage (with newlines) into the content.  Here's the output of my example run:

GET / HTTP/1.1
User-Agent: check_http/v1.4.16-61-g1845c (nagios-plugins 1.4.16)
Connection: close
Host: www.consumeraffairs.com


http://www.consumeraffairs.com:80/ is 30933 characters
STATUS: HTTP/1.1 200 OK
**** HEADER ****
Server: nginx/1.1.19
Vary: Cookie
Content-Type: text/html; charset=utf-8
Date: Thu, 06 Dec 2012 20:32:29 GMT
Transfer-Encoding: chunked
Connection: close
Set-Cookie: X-Mapping-fjhppofk=0F06A766EC4682365170E5AA67F0FDDA; path=/
Set-Cookie: X-Mapping-fjhppofk=0F06A766EC4682365170E5AA67F0FDDA; path=/
**** CONTENT ****
1f66
<!doctype html><!--[if lt IE 7 ]><html lang="en" class="no-js ie6"> ... (trimmed) ...

The '1f66' does not appear in the actual response, as verified with the browser, curl, wget, etc.  It appears it injects something like '1000', '2000', every few thousand characters, and a final '0' at the end.  I don't see these results against other hosts - ours appears to be 'lucky'.  We're running on nginx in Rackspace and using their load balancer service, but it reproduces running against a webserver on my laptop.

I ran in gdb, and it looks like the calls to `while ((i = my_recv (buffer, MAX_INPUT_BUFFER-1)) > 0) {` are injecting the garbage into the buffer, so it is somewhere in the read code.  Changing the buffer size or max read size appears to have no effect.  valgrind finds no reads of uninitialized memory.

It was breaking expected string checks, which is why we noticed it.  I'm turning off the expected string tests, so we'll just check 200 and timeouts.


----------------------------------------------------------------------

Comment By: Ferenc Wágner (wferi)
Date: 2012-12-07 01:40

Message:
Yes, this is actually #2786808: check_http asks for HTTP/1.1, but doesn't
understand chunked.

----------------------------------------------------------------------

Comment By: Graham (colling2)
Date: 2012-12-06 14:56

Message:
This is chunked data. Isnt the 'garbage' part of the way chunked data is
transmitted? Check_http probably doesn't understand chunking.

----------------------------------------------------------------------

Comment By: John Whitlock (jwhitlock)
Date: 2012-12-06 14:44

Message:
And also http://wordpress.com, which is an nginx site probably running
PHP+Wordpress.  Maybe this is an issue w/ nginx?

----------------------------------------------------------------------

Comment By: John Whitlock (jwhitlock)
Date: 2012-12-06 13:14

Message:
I found a few more sites with the problem:

http://www.disqus.com/
http://instagram.com/
http://www.mozilla.org/en-US/

Like us, they are all sites running Django:

https://www.djangoproject.com/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3593304&group_id=29880

More information about the Devel mailing list