monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTP_CONTENT_MAX and url method


From: Jan-Henrik Haukeland
Subject: Re: HTTP_CONTENT_MAX and url method
Date: Sat, 23 Apr 2005 02:51:11 +0200

Thanks for the heads up, HTTP_CONTENT_MAX should be 1MB now. New version checked into CVS.

On Apr 23, 2005, at 1:34, Ben Hartshorne wrote:

Thanks, Jan! Your fix solved the problem. The url method now correctly
pays attention to the HTTP_CONTENT_MAX value.  There's one more change
to make it perfect though; HTTP_CONTENT_MAX is currently set to 1024 *
10, which is 10k.  To match the docs claim of 1MB, it should be
1024*1000 or 1024*1024 depending on how you count...

The page I'm testing is actually 44k, so still didn't match my regex
using the default values. Capturing 100k is good enough for me (so I've
compiled it that way) but the docs do say 1MB...  ;)

Thanks a million!  That was a really fast bug fix!

-ben

On Fri, Apr 22, 2005 at 11:49:24PM +0200, Jan-Henrik Haukeland wrote:
Thanks for the report. I have checked in a fix in CVS. Can you please
see if this solve the problem. You can checkout the new version by
following the instructions here,
http://savannah.nongnu.org/cvs/?group=monit


On Apr 21, 2005, at 23:52, Ben Hartshorne wrote:

Hi everyone,

I am trying to use the 'url' method of monit 4.5.1, and have come
across
what seems to be a bug. Though the docs claim that monit will grab the
first 1MB of a file if the HTTP server does not specify a
Content-Length
header, it seems to only grab about the first 970ish bytes.

I first noticed this because my url content regexp test was failing,
though it seemed as if it should succeed.  I tried matching different
strings at different places in the document returned until I settled on
about 1000 characters.

I went poking around the code and found the HTTP_CONTENT_MAX variable,
which seemed to limit the amount of data scarfed if there was no
Content-Length header:
[excerpt from protocols/http.c]

 if(H->content_length < 0) /* Not defined in response */
   H->content_length= HTTP_CONTENT_MAX;
 else if(H->content_length > HTTP_CONTENT_MAX)
   H->content_length= HTTP_CONTENT_MAX;

I put in some debugging lines around this to make sure it was actually being run as I expected, and H->content_length is being set correctly.

I also put in a debugging line to print out what is contained in the
buffer allocated for the page, against which the regexp is tested.

I found that though reducing HTTP_CONTENT_MAX below 1000ish decreased
the amount of the page that was in the buffer, increasing it did not.
there was a cutoff at about 970, over which it seems to ignore
H->content_length.

I'm not up on my socket foo to go any further, but I wonder if anybody
has any insight into this problem.

I've attached protocols/http.c, my monitrc file (you're welcome to hit
my server to repeat the experiment), and the debugging output of
'./monit -I -v -c ./monitrc'

-ben

-- Ben Hartshorne
email: address@hidden
http://ben.hartshorne.net
<monitrc><http.c><monitout.txt>______________________________________ __
_______
monit-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monit-dev

--
Jan-Henrik Haukeland
mobile +47 97141255



_______________________________________________
monit-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monit-dev

--
Ben Hartshorne
email: address@hidden
http://ben.hartshorne.net
_______________________________________________
monit-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monit-dev

--
Jan-Henrik Haukeland
mobile +47 97141255





reply via email to

[Prev in Thread] Current Thread [Next in Thread]