[Tfug] HTTP file size limitation

Bexley Hall bexley401 at yahoo.com
Thu Sep 27 23:50:21 MST 2012


Hi,

OK, to recap:

1) 4.4GB (4,750,912,458) file downloaded (HTTP) via ancient
   Firefox *indicated* the file to be 4.4GB, but "stalled"
   at 435MB (455,945,162) transferred -- reporting "9% complete".

2) IE (also ancient) reported file as 434MB (?) and transferred
   all of that (455,945,162) before terminating normally (which
   is "incorrectly", in this case)

3) "Current" Firefox showed identical behavior to ancient version
   (i.e., upgrade made no difference).

4) NetBSD/i386 (5.1.2) running a very recent wget(1) reports
   file as 4,750,912,458 bytes, transfers same 455,945,162
   before stalling.

5) Access same site from public library (no idea what MS variants
   they are running) and all 4.4GB transferred.

6) Copy that 4.4GB file onto aforementioned NetBSD machine and
   access it via "current" Firefox -- but using an ftp:// URL
   and all is well.

[Tried setting up IIS on another XP box that was available
but XP vintage IIS can't serve up 4G files!  "MS:  bringing
1980's technology to the 21st century!" -- I should have
some bumper stickers made up!]

7) Build another NetBSD box, install Apache (2.4.3) and serve
   up the file via HTTP to the same Firefox (windows) client
   and all is well.

I've not gone back and verified the ancient Firefox works but
am very confident that it would (in the #6 or #7 scenarios).
Likewise, I suspect the ancient IE will crap out, regardless
(obviously using an uint32 to represent file sizes!  Sheesh!
one of these centuries, MS will step into the 1980's...)

The differences between the failing scenarios (1-4) and the
succeeding ones is the first four all used the original,
remote site to serve up the file (no idea what they were
using for an HTTPd).  This was also true of the 5th scenario
which used *none* of my software or hardware.

The 6th and 7th used my own servers but the same software
that had "failed" previously.

So, rule out the HTTP clients (at least, Firefox) and the
rest of the software running on this Windblows machine.

Real differences lie in the *service*.

But, the original server obviously works (with the clients
at the library).  And, the FTP/HTTP services *locally* also
work with the local clients.  So, even if they are different
pieces of software, it wouldn't explain the different results!

OTOH, scenarios 5, 6 and 7 all take place on a local internet.
While the modem is still in the picture, it is only acting as
a *switch* (i.e., I suspect it doesn't even support router
functionality on the "inside" interfaces!

Often, these devices use a 5 port switch with one port
wired to the "processor" (inside the modem) and the other
four ports exposed to the user directly.  So, there is
no real software peeking at packets that pass between
these 4 "exposed ports" (i.e., between this PC, the NetBSD
client and teh NetBSD server).

I.e., the modem is the problem.

Sheesh!

Oh, well... try updating the firmware (though it *claims*
to have the latest and greatest).

Now I can dismantle the NetBSD server... (boy, *really* nice
to be able to throw together a machine, add HTTP service,
etc. in less than an hour!)

I think I'll make some ice cream, first!

--don





More information about the tfug mailing list