Re: RES: Problems downloading files. How to identify the CANCEL b utto n?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Siomara,

On 7/11/2009 10:31 PM, siomara@portosdobrasil.gov.br wrote:
>         File                f        = new File(filename);

>         response.setContentType( (mimetype != null) ? mimetype :
> "application/octet-stream" );

If the content type is "text/[anything]", then you should also be
setting the response encoding along with the content type like this:

if(mimetype.startsWith("text/"))
{
    response.setCharacterEncoding(encoding); // whatever you want
    response.setContentType(mimetype + "; encoding=" + encoding);
}

>         response.setContentLength( (int)f.length() );

This is an error. You want:

response.setHeader("Content-Length", String.valueOf(f.length());

This will allow files larger than 4GB to have a correct content length.

>         byte[] bbuf = new byte[filename.length()];

As Pid suggested, creating a buffer based upon the file name length is
not particularly useful. Might I suggest a fixed buffer of a few kbytes?
Something like

byte[] bbuf = new byte[8192];

>         DataInputStream in = new DataInputStream(new FileInputStream(f));

Again, DataInputStream is inappropriate, but you aren't using any
DataInputStream-specific methods, so it doesn't matter. It does indicate
that you are not choosing appropriate API classes for your purposes, though.

>         while ((in != null) && ((length = in.read(bbuf)) != -1))
>         {
>             op.write(bbuf,0,length);
>         }

I'm not sure the null-check is necessary for the 'in' variable, but
otherwise this is fine. Explicitly calling in.read(bbuf, 0, 8192) would
give you a (probably neglegible) performance improvement by avoiding
another method call.

>         // The lines bellow will retrieve information from request and
>         // register them into the database (interested user ID/file ID/ and
>         // licitation ID). The problem, as I said, is that by the time the
>         // download manager window (that this code displays) shows up the
>         // entire code has been already executed.
>         int interessadoID = Integer.parseInt(request.getParameter("int"));
>         int arquivoID = Integer.parseInt(request.getParameter("arq"));
>         int licitacaoID = Integer.parseInt(request.getParameter("lic"));

I would parse these values /before/ doing anything else. If an error
occurs, here, then the user can get their files without leaving a trace.

>     /**
>      * Handles the HTTP POST method.
>      * @param request servlet request
>      * @param response servlet response
>      */
>     protected void doPost(HttpServletRequest request, HttpServletResponse
> response)

Is it appropriate for a POST to result in a large file download? I
suppose only you can make this decision.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpbNjEACgkQ9CaO5/Lv0PATyACfRALTtxgNHVSknE+QkAfGcJCt
EfQAn31ls4vGLT8U7WqgoA8YQg+vRRqP
=Bq/8
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org