ryah ([info]four) wrote,
@ 2006-12-18 10:53:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:projects, upload progress bar

non-ajax http upload progress bar
HTTP upload progress bars are rather obfuscated- they typically involve a process running on the server keeping track of the size of the tempfile that the HTTP server is writing to, then on the client side an AJAX call is made every couple seconds to the server during the upload to ask for the progress of the upload.

This is pretty ridiculous. Making million of AJAX requests (which probably slow down your upload) just to poll the server on this trivial fact? Your browser knows how much data you've sent - the best solution would be to have this information stored in the DOM. As far as I can tell, this is not happening.

Xupload is a beautiful hack to do this without AJAX. When you start your download it streams an HTML back back to you very slowly. The first part of the HTML is normal, with elements defining the progress bar, javascript, etc., this comes all at once. Then comes information about your upload in progress incrementally as javascript calls:

<script>SP(4,0,0,0,0);</script>
<script>SP(8,0,0,0,0);</script>
<script>SP(8,1,8,0,2);</script>
<script>SP(12,1,12,0,1);</script>
These javascript calls update the progress bar above. (SP($size,$time,$speed,$files_uploaded,$time_left)) Basically: you're loading a single page, and as it loads the progress bar moves.



(13 comments) - (Post a new comment)


[info]nikolasco
2006-12-18 03:38 pm UTC (link)
This seems like the obvious way to go, as a JS successor to multipart/x-mixed-replace.

(Reply to this) (Thread)


[info]evan
2006-12-20 01:07 am UTC (link)
The reason this isn't more popular, as I recall, is that it doesn't work in IE.

They're working on better upload support in newer HTML standards, I'm sure, but nobody cares because none of the browsers will support it for another five years.

(Reply to this) (Parent)


[info]codetoad
2006-12-18 11:09 pm UTC (link)
Can you explain this in more detail? Your explanation mentions "download?" Where is it downloading this information from? It's all client-side JS? So there's a call to obtain the size of a file you're sending and how much you've sent? What's the call?

(Reply to this) (Thread)

I think it works like this:
[info]four
2006-12-19 01:20 am UTC (link)

  1. Server sets a unique upload id and embeds it in the upload form that it sends to users.

  2. The user chooses a file with the form and clicks upload.

  3. A javascript popup window opens, which will display the progress bar. The upload id is passed to this loading page. Meanwhile the form page sends a request to its action and begins uploading the file.

  4. In the popup, the server is pushing a stream of javascript commands SP(,,,) at the end of the HTML

  5. Each of these javascript commands updates the progress bar.
Or more simply, the server could just push a txt page that looked like this:

0%
1%
5%
.
.
.
70%
78%
92%
100%

which would effectively be the same thing. The javascript just makes it look fancy.

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]four
2006-12-19 01:22 am UTC (link)
yeah. I don't know if that was a good explanation.

I forgot to mention that the upload id is used so that the popup request knows which file the other window is uploading.

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]codetoad
2006-12-19 01:58 am UTC (link)
How does the downloaded command correspond to the upload progress, though?

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]four
2006-12-19 02:03 am UTC (link)
the as the server loads the popup window it is polling the size of the tempfile that the request is uploading into (it can figure out which tempfile with the upload id).

then it writes one of these "percent complete" javascript commands once every x seconds.. the novel thing is that this is all one server response and not multiple - it's just writing just a little more to the html file every x seconds.

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]codetoad
2006-12-19 04:07 am UTC (link)
Okay, I can see that (given the HTTP request doesn't time out). How does the server know the total size of the file?

Sorry for asking so many questions, but I'm curious and you made a post about this :)

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]four
2006-12-19 04:31 am UTC (link)
I think that information is sent when you upload a file? so i guess the webserver knows (Content-length)

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]codetoad
2006-12-19 04:50 am UTC (link)
Yeah, that makes a lot of sense! Thanks for explaining.

It seems like this would be useful if you could set an HTTP timeout for these specific returned files. Having a long HTTP timeout is bad..

(Reply to this) (Parent)(Thread)

Re: I think it works like this:
[info]four
2006-12-19 04:53 am UTC (link)
its definitely a hack.

we need the browsers to just tell us how much they've sent. what's so hard about that? shit.

i wonder if webdav can provide this sort of information...

(Reply to this) (Parent)


[info]nibot
2006-12-19 03:26 pm UTC (link)
I guess "beautiful hack" doesn't mean what it used to. (-:

DOM? AJAX? Is this the Ryah I knew?

(Reply to this) (Thread)


[info]evan
2006-12-20 01:08 am UTC (link)
I think since everything with web stuff is going to be sick, it's implicit and you're left with "beautiful hack, which is still sick of course but at least beautiful when compared to the sickness you're normally faced with".

(Reply to this) (Parent)


(13 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…