I'm working on the "right way" to upload files
of multiple gigabytes from customer browsers
to a server (break it up, make multiple posts of
the pieces). In the meantime, a customer would
like an immediate workaround to upload big files
to a servlet-based app running on Tomcat 5 on
Solaris 9. The client is sometimes
Netscape 7 on Solaris, sometimes IE 6 on Windows.

I've updated several layers - changed int to long
in the Java servlet that's receiving the files,
and edited all the limits I can find in the Tomcat
configuration files. I can stuff the filepath of a
4Gb file into a <input type=file> on the client,
but the server still sees an http request body of zero length.
I'm looking at the request with O'Reilly's MultipartRequest
class.

When the client is IE, I see a "server not found" in
IE, which makes me suspect the server never gets a
chance to respond in that environment.

None of the resources I've been able to find consider
this case. Is 2Gb a hard limit in the clients I have
to support? Is there good documentation on this
that I haven't found yet?

I know one workaround is to break up the huge files
into smaller 2Gb files, but the original huge files
are compressed tars that contain tens of thousands of files,
so breaking them up requires undesirable extra work
repackaging the original stuff.

Thanks.

--
Glenn Holliday holliday@acm.org

Glenn Holliday wrote:
> I'm working on the "right way" to upload files
> of multiple gigabytes from customer browsers
> to a server (break it up, make multiple posts of
> the pieces). In the meantime, a customer would
> like an immediate workaround to upload big files
> to a servlet-based app running on Tomcat 5 on
> Solaris 9. The client is sometimes
> Netscape 7 on Solaris, sometimes IE 6 on Windows.
>
> I've updated several layers - changed int to long
> in the Java servlet that's receiving the files,
> and edited all the limits I can find in the Tomcat
> configuration files. I can stuff the filepath of a
> 4Gb file into a <input type=file> on the client,
> but the server still sees an http request body of zero length.
> I'm looking at the request with O'Reilly's MultipartRequest
> class.
>
> When the client is IE, I see a "server not found" in
> IE, which makes me suspect the server never gets a
> chance to respond in that environment.
>
> None of the resources I've been able to find consider
> this case. Is 2Gb a hard limit in the clients I have
> to support? Is there good documentation on this
> that I haven't found yet?

Do you absolutely, positively, have to use the browser without any
? You've already got a Tomcat server running, so why not use a Java
applet? Most people would avoid using a Java applet in this context
because they'd say "Oh, then I have to go through all the work of
setting up a Tomcat server." But you've already got a Tomcat server
running, so what is the problem? Seems like there is a wealth of
options:

http://www.google.com/search?q=java+...en-US:official

Thanks Jake.
Jake Barnes wrote:
> Glenn Holliday wrote:
>> I'm working on the "right way" to upload files
>> of multiple gigabytes from customer browsers
>
> Do you absolutely, positively, have to use the browser without any
> ? You've already got a Tomcat server running, so why not use a Java
> applet?

We started out with that thought, but the customer has
heavy-duty CM and didn't want to apply up the
chain for permission to execute an applet on their
users' desktops. I think it's becoming more likely
that we'll go in that direction after all.

--
Glenn Holliday holliday@acm.org

Thanks Jake.
Jake Barnes wrote:
> Glenn Holliday wrote:
>> I'm working on the "right way" to upload files
>> of multiple gigabytes from customer browsers
>
> Do you absolutely, positively, have to use the browser without any
> ? You've already got a Tomcat server running, so why not use a Java
> applet?

We started out with that thought, but the customer has
heavy-duty CM and didn't want to apply up the
chain for permission to execute an applet on their
users' desktops. I think it's becoming more likely
that we'll go in that direction after all.

--
Glenn Holliday holliday@acm.org