Endpoint Protection

 View Only
  • 1.  ISS w3svc1 log showing 304 0 0 status on "GET" of Livetri.zip file

    Posted Jan 11, 2010 04:52 PM
    While doing some cleanup to reclaim hard disk space on our SAV 10.2 corporate server I was pruning through old IIS logs and noticed a lot of the clients listed were receiving a 304 0 0 status on the GET of the livetri.zip file, like this below:

    2010-01-11 21:34:12 W3SVC1 SERVER IP GET /livetri.zip - 80 - CLIENT IP yJ/KkasXRLP/9SO+NUkAwgeBPn8TJlLSwAAAAA 304 0 0

    I know 304 status corresponds to "not modified" but I am not sure what that means in the grand scheme of trying to download the livetri.zip file? Can anyone chime in on this and the potential causes?


  • 2.  RE: ISS w3svc1 log showing 304 0 0 status on "GET" of Livetri.zip file
    Best Answer

    Posted Jan 11, 2010 11:33 PM
    Hi,

    The livetri.zip file is the master catalog file of all the products of Symantec that can be updated via liveupdate. it also contains the latest revision number of the definitions for those products.

    So, if a client is doing a liveupdate session in a frequent manner, its possible that the new revisions for SAV or any other product have not been released by Symantec yet. So, the livetri.zip file remains the same.

    Thats the reason the clients can get the return code 304.

    Note: LiveUpdate clients that connect to Symantec servers do not use the Livetri.zip file.

    I hope that answers your question.

    Aniket



  • 3.  RE: ISS w3svc1 log showing 304 0 0 status on "GET" of Livetri.zip file

    Posted Jan 12, 2010 07:59 AM

    So, if a client is doing a liveupdate session in a frequent manner, its possible that the new revisions for SAV or any other product have not been released by Symantec yet. So, the livetri.zip file remains the same.
    Since this is not modified you get 304 status which corresponds to "not modified"


  • 4.  RE: ISS w3svc1 log showing 304 0 0 status on "GET" of Livetri.zip file

    Posted Jan 12, 2010 10:24 AM
    Great thanks that is very helpful, this is in an environment where the clients connect in (via VPN) to a dedicated internal LiveUpdate server so the 304 status appears to be perfectly normal.