Return-Path: 
 <commons-dev-return-60726-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 96728 invoked from network); 15 Oct 2004 04:01:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 15 Oct 2004 04:01:15 -0000
Received: (qmail 93609 invoked by uid 500); 15 Oct 2004 04:01:11 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 93489 invoked by uid 500); 15 Oct 2004 04:01:10 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 93476 invoked by uid 500); 15 Oct 2004 04:01:10 -0000
Received: (qmail 93472 invoked by uid 99); 15 Oct 2004 04:01:10 -0000
X-ASF-Spam-Status: No, hits=-10.0 required=10.0
	tests=ALL_TRUSTED,NO_REAL_NAME
X-Spam-Check-By: apache.org
Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194)
  by apache.org (qpsmtpd/0.28) with SMTP; Thu, 14 Oct 2004 21:01:10 -0700
Received: (qmail 96661 invoked by uid 1339); 15 Oct 2004 04:01:09 -0000
Date: 15 Oct 2004 04:01:09 -0000
Message-ID: <20041015040109.96660.qmail@minotaur.apache.org>
From: martinc@apache.org
To: jakarta-commons-cvs@apache.org
Subject: cvs commit: jakarta-commons/fileupload/xdocs using.xml
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

martinc     2004/10/14 21:01:08

  Modified:    fileupload/xdocs using.xml
  Log:
  Bug #27193 - Some documentation on interaction with virus scanners.
  
  Revision  Changes    Path
  1.4       +34 -0     jakarta-commons/fileupload/xdocs/using.xml
  
  Index: using.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-commons/fileupload/xdocs/using.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- using.xml	25 Feb 2004 21:07:12 -0000	1.3
  +++ using.xml	15 Oct 2004 04:01:08 -0000	1.4
  @@ -233,6 +233,40 @@
   ...]]></source>
     </section>
   
  +  <section name="Interaction with virus scanners">
  +    <p>
  +      Virus scanners running on the same system as the web container can cause
  +      some unexpected behaviours for applications using FileUpload. This section
  +      describes some of the behaviours that you might encounter, and provides
  +      some ideas for how to handle them.
  +    </p>
  +    <p>
  +      The default implementation of FileUpload will cause uploaded items above
  +      a certain size threshold to be written to disk. As soon as such a file is
  +      closed, any virus scanner on the system will wake up and inspect it, and
  +      potentially quarantine the file - that is, move it to a special location
  +      where it will not cause problems. This, of course, will be a surprise to
  +      the application developer, since the uploaded file item will no longer be
  +      available for processing. On the other hand, uploaded items below that
  +      same threshold will be held in memory, and therefore will not be seen by
  +      virus scanners. This allows for the possibility of a virus being retained
  +      in some form (although if it is ever written to disk, the virus scanner
  +      would locate and inspect it).
  +    </p>
  +    <p>
  +      One commonly used solution is to set aside one directory on the system
  +      into which all uploaded files will be placed, and to configure the virus
  +      scanner to ignore that directory. This ensures that files will not be
  +      ripped out from under the application, but then leaves responsibility for
  +      virus scanning up to the application developer. Scanning the uploaded
  +      files for viruses can then be performed by an external process, which
  +      might move clean or cleaned files to an "approved" location, or by
  +      integrating a virus scanner within the application itself. The details of
  +      configuring an external process or integrating virus scanning into an
  +      application are outside the scope of this document.
  +    </p>
  +  </section>
  +
     <section name="What's next">
       <p>
         Hopefully this page has provided you with a good idea of how to use
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org