That does indeed appear to be an amusing gem. The explanation likely lies in the underlying implementation actually having two timers, one for the client and one for the server. I'm speculating, but if not for something along those lines, certain denial of service attacks could be easier to implement against ELB and the machines behind it.
The answer will lie in the ELB access logs. If you see times suspiciously close to 60 seconds, you have a likely culprit.
Increasing the timer may be one option.
Typically, though, it seems like web apps need to be in and out, over and done, moving on to whatever is next, within milliseconds. Tying up a process or a thread with something long-running like an upload means hundreds or thousands of other requests you might have been able to handle, if not for that resource hog of an upload. File uploads of really large files might be better handled by delegating them to a separate environment or service (such as S3, which can accept a POST upload, then redirect the browser back to your "success" page when the upload is done). Other tactics might include smart client logic to send the upload in parts, maybe in parallel, with the ability to restart/retry and do other clever things like progress bars.
I have probably 20-30 ELB deployments at ${dayjob}, and this has never come up, but then I don't have any systems that deal in "large" files on the user-facing side. A "large" upload for these systems that I am thinking of might be 16MB, so definitely a different scale.
