Poss. BUG in IMON

Discussion in 'NOD32 version 2 Forum' started by Snarfster, Jan 8, 2007.

Thread Status:
Not open for further replies.
  1. Snarfster

    Snarfster Registered Member

    Joined:
    Jan 8, 2007
    Posts:
    4
    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
     
  2. ASpace

    ASpace Guest

    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 .
     
  3. Snarfster

    Snarfster Registered Member

    Joined:
    Jan 8, 2007
    Posts:
    4
    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
     
  4. ASpace

    ASpace Guest


    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
     
  5. Snarfster

    Snarfster Registered Member

    Joined:
    Jan 8, 2007
    Posts:
    4
    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.
     
  6. ASpace

    ASpace Guest

    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 :)
     
  7. Snarfster

    Snarfster Registered Member

    Joined:
    Jan 8, 2007
    Posts:
    4
    Talked to San Diego office. Very nice and helpful. We worked out solutions that will help everyone going forward.
     
  8. ASpace

    ASpace Guest

    Glad . Thanks for letting me know ! ;)
     
  9. UnixMan

    UnixMan Registered Member

    Joined:
    Feb 18, 2007
    Posts:
    1
    Location:
    Australia
    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." )
     
Thread Status:
Not open for further replies.