Comments for Wishful Coding

Comment on How to install Python/web.py on a shared host by Ward

Ward — Mon, 08 Mar 2010 11:17:12 +0000

You can always take a look at ramhost.us VPS-servers, they are $3 / month and you can install whatever you like.
If you take a look at most shared hosting a VPS is cheaper there, and it’s great quality.

Comment on Cross-domain caching by Pepijn de Vos

Pepijn de Vos — Wed, 24 Feb 2010 19:59:12 +0000

Dit bericht gaat over het opslaan van data van websites, zodat je ze niet elke keer opnieuw hoeft te laden, dat noem je caching.

De bedoeling is dat ik dingen schrijf over computers wat ik tegen kom, en dat mensen die dat interessant vinden dat dan kunnen lezen en er op reageren.

Comment on Cross-domain caching by Jean-Pierre de Vos

Jean-Pierre de Vos — Wed, 24 Feb 2010 17:59:19 +0000

Hoi Pepijn,
Kun je aan een domme oom die digibeet is uitleggen waar dit over gaat want hoewel ik de engelse taal toch redelijk kan volgen geld dat absoluut niet voor het bezoek aan deze grappig uitziende maar voor mij onbegrijpelijke site.Wat is de bedoeling.Jean-Pierre

Comment on Cross-domain caching by Peter Robinett

Peter Robinett — Sun, 21 Feb 2010 01:43:48 +0000

There is no set-in-stone standard on what seed an ETag should be generated from. You are correct that it is often encouraged to use the modified date but I actually like using the entire file instead as the seed (many languages have functions that will do this for you), as we already have If-Modified-Since for time-based caching tests. And since the whole point of hashing algorithms such as MD5 and, better yet, SHA1 is that they give you the same output for the same input, I think ETag basically does what you want. God knows that people are good enough at messing up existing HTTP headers, so I think it’s more a matter of implementors putting their feet down and building good systems rather than defining a new standard header.

So, you could start to implement this today. Just have your HTTP client (web browser or what have you) associated ETags not only to entire URLs but also to just the final, file portion. When visiting a new site first send check ETags for cached files based upon the site’s file’s full URL, then try an ETag for another site’s URL whose file name matches, and finally only download the file if the first two options have failed.

However, I wouldn’t recommend doing this, as this is rife for abuse and is essentially a cross site scripting attack. Just think about malicious sites sending out malicious files associated with known good hashes (e.g. malicious code backed by the ETag of a known jQuery release), only for users to execute the cached, bad code when visiting a banking website. Of course, if you know how the ETag is generated the client can recalculate the hash against the file you’ve received and throw out the file if they don’t match…

All in all, it’s an interesting though and might be really interesting to see in action.

Comment on Cross-domain caching by Pepijn de Vos

Pepijn de Vos — Sat, 20 Feb 2010 18:56:54 +0000

ETags are based on modified date and other local stuff, as per the wiki link you included.

I do not know anything about hashing algorithms, but if Ubuntu can provide a MD5 sum on their website to verify the download, I’d think MD5 sums can be generated in a persistent manner.

Comment on Cross-domain caching by Peter Robinett

Peter Robinett — Sat, 20 Feb 2010 17:12:38 +0000

Pepijn, ETags are basically what you’re talking about, a hash that the HTTP client can pass to the server to see if they’ve changed: http://en.wikipedia.org/wiki/HTTP_ETag. However, there is no guarantee that ETags are calculated the same from one server to another, meaning that using them across domains would be very risky. In general, even if you had a standard to require people to all use the same hashing algorithm, there would be too many opportunities for errors, whether accidental or deliberate.