Poss. BUG in IMON

Hi,

We're the developers of Snarfer (RSS reader - snarfware.com) and have discovered a serious issue in IMON. Users of Snarfer (noticed issue within past 30-45 days) who have IMON turned on are having their GET requests w/ headers sent twice together as one request. Main issue beyond that is the last line of the headers is /r/n/r/n as expected but last /r/n is on a new line without expected colon which causes an apache bad request error (all header lines must has colon in it).

If you turn off IMON then Snarfer works fine.

HELP please. Was there an IMON update pushed out to users within past 60 days? This issue has killed thousands of Snarfers out there. We need to resolve this ASAP.

Cheers,
Kirk

 

Hi . In IMON -> Setup -> Miscellaneous tab add this application in the exclusions list so that IMON doesn't scan it at all .Make sure to add all related applications to that list , too . Reboot and try if it is working

nothing special to IMON .

 

that's not the issue. Snarfer doesn't do anything that should require that extreme measures since it only uses http. this issues is also effecting other apps. and causing browsers to run really show (esp. https connections).

here's the data stream... notice 1) IMON is duplicating the GET request and 2) is ending the stream with /r/n on a new line without a colon (which is causing an apache bad header request).

GET /feeds/feeds.atom HTTP/1.1/r/n
Accept: */*/r/n
Accept-Language: en/r/n
Host: www.snarfware.com/r/n
Connection: Keep-Alive/r/n
Accept-Encoding: gzip, deflate/r/n
User-Agent: Snarfer/0.7.0 (http://www.snarfware.com/)/r/n
GET /feeds/feeds.atom HTTP/1.1/r/n
Accept: */*/r/n
Accept-Language: en/r/n
Host: www.snarfware.com/r/n
Connection: Keep-Alive/r/n
Accept-Encoding: gzip, deflate/r/n
User-Agent: Snarfer/0.7.0 (http://www.snarfware.com/)/r/n
/r/n


Cheers

 

IMON scans only HTTP traffic and POP3 so IMON does scan your application . IMON works on Winsock level and is incapable of scanning HTTPS traffic .

Please , try to repair Winsock if you think this may help , reload IMON and exclude this application from scanning . Otherwise , contact ESET directly and provide them with information so that they can resolve the issue

 

let me correct previous post..

it's the GET statment added to middle of request (missing a colon) that's causing an error. the server doesn't know the a GET in the middle isn't a header and it's expecting a colon on that line.

sorry for my mispost.

 

Sorry , Snarfster , I can't help you . If you don't want to do what I already advised you , please contact ESET Tech Support (mail to support@eset.com) with a short description and a link to this thread . I'm sure they can help you

 

Talked to San Diego office. Very nice and helpful. We worked out solutions that will help everyone going forward.

 

Glad . Thanks for letting me know !

 

I am having a similar problem [Apache from xampp running under XP SP2 acting as a reverse proxy to rails] (thought turning imon off then back on has temp. fixed the problem).

What was the solution you ended up with please?

This does seem to be a reaccuring issuse (Eg Dec 2005 - the following describes my symptoms - http://issues.apache.org/bugzilla/show_bug.cgi?id=34716 was marked closed/invalid (ie not an apache bug) with the last comment being
"As the error seems to be caused by a virus scanner product installed on the
boxes I mark this report as invalid." )