evølutiøn-515.net » JavaScript

Uploads via HTTP are still an issue…

Blu:RayNe — Sun, 01 Feb 2009 21:33:05 +0000

Even in the days of Web 2.0 you encounter many errors when it comes to Uploads via HTTP. The protocol was never made for uploads or better to say: there are still enough bugs in implementations and the protocol itself.

Very familar, e.g. is the problem of having a meter on upload progress. And i also don’t want to mention the problems of WebDAV implementation of Windows for now, or the limitations of firewalls or proxies…

But let’s have a look on solutions provided today in the Web for Uploads…

Flash/HTTP

We have a modified version of R6 running on a webshop with regular uploads of 20-70MB files. If upload goes to fast – like on business lines with upstream ≥3Mb – Flash is likely to throw errors telling the visitor a script is running too slow. Then the customer has to choose „continue“ or to „cancel“, which usually ends up in canceling the job

This behavior is caused by Flash calling the „onFileChunkComplete“-Event (or something) too often, or let’s say after every 4096 bytes sent, which can result in many many calls if you have a good upstream bandwidth.

Second, there are also those „unknown errors“ in Flash caused at runtime. The source yet is unknown and it seems to continue with Flash10 and some little amount of customers smaller than one percent share. Sorry, unknown means unknown and Adobe won’t give support here! we’re back to Flash9

Yet the same thing happens to JavaScript if update goes too fast and too often, e.g. by using a progress bar constantly being updated (20-50times in the second). Therefore I had to split up the graphical update process to a seperate class that just goes on update intervals calling the current/total-values of the FileUpload-Class.

Well using Flash as upload client is nice, especially with the ability to use real sockets. For Flash9 the HTTP methods don’t provide the possibility of splitting large files – so you could upload them in seperate chunks. It’s about security.

Then Flash10 possibly could do now (by accepting local files), but here we have the issue of having the upload beeing fired from Flash itself – scripting doesn’t work anymore, so no hidden flash uploader, that could do the job

But customer complaints still continues… especially form those using MSIE and don’t get a thing right.

PHP and APC, for now. HTTP again…

Okay, usually you gotta think this works now. It’s out now for long enough. But fail of proof!

I leeched some script form PHPRiot yesterday by Quentin Zervaas, fixed some bugs (while(1=1) is great idea in JavaScript ), added a file limit check and hoped i finally would have something that really works. But it didn’t:

Multiple file-fields do not work with APC
If file uploaded is greater than far greater than limit, apc throws out 0-values for current and total
Sometimes just seems stop working somehow; but after an apache restart apache it works again

I tried so many ‘solutions’ now and somehow it really seems to me, that monitoring the upload by calling a server-side status-script always has some problems. Probably it is really an Apache-issue… we’ll have too see…

Sliced HTTP Upload via Plugins – a solution?

I already mentioned it in the Flash/HTTP section, and indeed it’s more safe, because the file chunks are simply smaller!

I did many tests with Apache, and often it just happens that Apache closes a TCP connection on big file uploads. The source is yet unknown to me. Probably it has to do with Apache itself. I didn’t encounter the problem when using FastCGI and a Perl-Script to handle my upload.

So, i guess doing sliced upload is a good option. But then you could only use Flash10 which has other restrictions or Java. Yep, that thing that only works on 70-80% of user browsers, MSIE for the rest that reports about having Java supported – true indeed – the other problem is: does it really run on those often misconfigured and compromised customer systems?

Well Flash10 now does, but have some limitations we probably could live with:

load() and save() APIs can only be called in response to user interaction (such as a button click).
locations of the loaded and save files are not exposed to ActionScript.

Since the API is now asynchronous (non-blocking),

Final match: HTTP vs. FTP-Uploads in the client

HTTP was not made for upload!
use more bandwidth than you actually need (base64!)
HTTP is not resumeable (but you could retry on splitted chunks)

Let’s summariuze: You can only monitor what was uplaoded by having control over your client and you can only split files, when you have access on it.

Use a Java-Applet or code a Flash-Client that works over FTP! And use a FTP-Server that is secure and can handle virtual users, like vsftpd. Then code some backend,

Yes! Probably it is a solution. But you still have the problems with users not supperting Java, or who complain about Java „loading“ too long. Here are some other good tries, that usually work:

We’ll see further when the first FTP libraries for Flash 10 are finished.

Custom fonts: text replacement via Canvas and VML

Blu:RayNe — Tue, 28 Oct 2008 13:29:55 +0000

Still we have to wait until @font-face is ready in all modern browsers. We had text-replacement by Flash, by images created on the server and by half-working SVG so far. Now it’s time for another approach: text replacement via pure Javascript!

Basically the script draws JSON font outlines converted via a Perl-Script from TTF and uses both VML and Canvas for rendering. Only problem: text cannot be selected and copied to the clipboard anymore.

There’s work left to be done. Planned improvements:

Full support for @font-face rules, if possible

Support for hinting (this seems like a viable option)

Speed improvements, especially for IE

Work around Opera’s getComputedStyle() issues

Possible support for SVG backend

Work around needing to specify ‘typeface-js’ as a class name

More CSS support, including :hover and x-height

React to DOMNode* events to support DHTML

Great job: It’s working on all major modern and semi-modern browser (MSIE7). I’ll be using that! Thanks!

More here: http://typeface.neocracy.org/

DOJO needs a package managment!

Blu:RayNe — Mon, 25 Feb 2008 13:21:41 +0000

I needed some locale date and number parsing fucntion for javascript today. As it goes for what the user sees i do usually do parsing and validation on the server-side. But this time i needed something for an admin interface that does also some javascript-based price calculation on the client-side.

So far i searched via Google for Prototype-based Libs on i18n, sprintf and so on. I found JEL (JavaScript Enhancement Library) and gave it try, but hardly to say: it is too bloated and the author implemented much english-language based method, but so far no sprintf, which i find is essential. And in overall the lib was ober 200KB for only doing I18n stuff!

Then i found out DOJO implements Date.POSIX and also a a String.sprintf that seemed very complete and began browsing the DOJO-Website. DOJO so far is IBM-sponsored and it was nice to see it reached a mature stage of development. I don’t like the namespaced function calls in JavaScript much, but on the server side doing java stuff like in GWT would be nice with that.

Still one big problem remains with DOJO: it just fucking hangs my browser and loads too damn slow!

DOJO has a nice dojo.require() which loads required dependencies on-the-fly. I had my own approach on that via the Prototype-based Postload.js. But the main problem with DOJO is that every class has again it’s own dependencies. You just have to inlcude one line of javascript in your HTML header, but when you do following require-statements…

dojo.require("dojo.date.locale");
dojo.require("dojo.currency");
dojo.require("dojo.i18n");

… it results in firing up about 40 requests on .js-files! That’s horrible! No wonder, my little Firefox hangs until all files are loaded! So, please, don’t harm the web, DOJO!

I don’t know if there is any solution out by the DOJO team, so please tell me. My conculusion so far is that for default load process of the website the dependencies should be resolved before the page is even sent to the browser. The browser should have just to load one JavaScript-file that is compressed and contains all default dependencies used by DOJO on the page. So far that can only be done having a little reference of all dependencies, so the haeder can be written accordingly.

If there isn’t such a thing someone should do that! So far I think think DOJO is a good for my future use, as long as there isn’t an Prototype- or jQuery-equivalent for i18n.

KAURI has also a nice comparision chart of JavaScript-libraries.

UPDATE #1: Probably i could now also check out localisation-support for Ext.js… which seems to miss parse()-functions (or does it automatically). And in overall i don’t find any great localisation support either

UPDATE #2: There seems to be such a thing for DOJO called DOJO Build System that uses ant. It could be used as base for automatic server-side file generation in PHP… great I just everyone who uses DOJO is also using it, otherwise I am gonig to hate your websites!

Prototip: Now does AJAX with this little Extension.

Blu:RayNe — Fri, 30 Nov 2007 13:37:56 +0000

Prototip.js is my favorite prototype.js-based tooltip-script at the moment. I’ve just written this piece in morning because we needed the capability of having dynamic content (or postloading big bits of HTML with images). Enjoy!

/**
* AjaxTip
* @version 0.1
* @desc Extension for prototip.js. Now it supports dynamic loading of content. (http://www.nickstakenburg.com/projects/prototip/)
* @author Markus Geiger 2007
* @package AjaxTip
* @license MIT
* @url http://blog.evolution515.net
*/

// Initialize Tip
var content = ‘ Loading…’;
this.tip = new Tip(
this.elem,
content,
this.options
);

// Make AJAX Request and load content
var tip = this.tip;
this.request = new Ajax.Request(
this.href,
{
method: ‘get’,
onSuccess: function(transport) {
tip.content = transport.responseText;
tip.tip.innerHTML = transport.responseText;
}
}
);

this.elem.tip = this.tip;
Event.stopObserving(this.elem, ‘mousemove’, this.eventMousemove);
}
});

And here’s a replacement for a better default CSS style:

/* Tooltip styles */
.prototip .default {
width: 150px;
}
.prototip .default .toolbar {
background: #FFE;
}
.prototip .default .title {
padding: 5px;
}
.prototip .default .content {
background: #FFE;
font-size: 11px;
font-family: Arial, sans-serif;
padding: 6px;
text-align:left;
min-height:1em;
width:200px;
color:#000;
border:1px solid #999;
border-radius:5px;
-moz-border-radius:5px;
}

You can create a neat AJAX-Loader GIF here. Use #FFFFDD for background and #999999 for foreground color.

Post-load your JavaScript and CSS files!

Blu:RayNe — Wed, 25 Jul 2007 17:45:09 +0000

If you look at todays web 2.0 sites you will realize there is often a heavy load on external JavaScript resources, CSS files and probably images. Above compressing and optimizing the files and merging multiple files (also background-images), there is not much room to further optimize the page loading process.

One problem of many modern sites is that they often provide optional functions for the user at the price of loading the main libraries all at once ending in a terrible site- and javascript-performance. I’ve already spoken about that once before and see more and more a good chance for web-applications based on Flex, or a real interface-language or perhaps Java. But we’re speaking about web-sites here not applications (anyway you could intermix them)!

Imagine a „passage-way“ or „pass-by“ page: How many of your users will use your “godly” fully featured search-window that you’ve implemented with Ext or the Prototype Window-Script and that runs inside the page? And what about overall JS and CSS footprint about 150KB? Really needed? And oh, it’s the only part of the website you’re using these scripts.

Maybe one of ten users will use your “godly” feature. The others all have to load the site, the slow JavaScript and you will pay bandwidth.

So, why don’t you just simply load the parts of the site when you need them? AJAX – it’s all about that but still people are loading tons of libraries on every single site!?

As you might guessed i worked on such a script today. It works pretty well in Firefox and Opera (not yet Safari and fucking MSIE), and i still have to come up with some issues and heavy testing (especially on older browser that probably don’t wanna let their DOM injected JavaScript or CSS; so a good wrapper for