Earlier quoted context omitted.
If you give the url of the photo you are allowed to see to someone else, you can give the actual photo as well. I don't get the security risk here.
If the urls are guessable then someone could harvest images without having been given urls by authorized users.
Small things add up: 4chan's migration to a cookieless domain
121–130 of 139 posts
Re: Small things add up: 4chan's migration to a cookieless domain
#122We wanted to do this at a news site I worked for (since we had way too many cookies) but the problem was Google news. On Google news thumbnails would not be shown unless they came from the same domain as the other page. So our content was on "www.example.com" and pictures were on "media.example.com" but the cookies were for "example.com" so got sent with every image request.
Set cookie for www.example.com?
Re: Small things add up: 4chan's migration to a cookieless domain
#123Earlier quoted context omitted.
No need, because you can gzip compress, which will make even better savings than that (because it can also compress and save space taken by tags etc, not just class names).
You could do that and gzip though; it would probably yield some savings. An obfuscator generating code à la iocc efficiency would be quite neat (e.g. http://www.ioccc.org/2012/endoh1/endoh1.c )
Nope. That's classic non-engineer thinking. The same kind of thinking that does "optimization" without profiling.
Let me introduce you to my friend: http://en.wikipedia.org/wiki/Diminishing_returns
Re: Small things add up: 4chan's migration to a cookieless domain
#124Re: Small things add up: 4chan's migration to a cookieless domain
#125I doubt domain length will really make any difference, gzip compression should take care of a longer domain name.
The 50 bytes figure represents a compressed response. (We actually write all of our pages compressed to disk before serving them -- nothing is served dynamically. But that's for another post...) The example below isn't the most scientific, but should give you a rough idea. Test index page with different static URLs: URLs as 4cdn.org -- 23261 bytes compressed URLs as 4chan-cdn.org -- 23311 bytes compressed URLs as 4ch…
Re: Small things add up: 4chan's migration to a cookieless domain
#126Earlier quoted context omitted.
Thanks for pointing that out. We minify production JS using Closure Compiler but sometimes that leaves room for improvement. There's definitely a tradeoff between inlining JS and small images, but I think in our case it makes more sense to leave them external to leverage browser (and since we use a CDN for static content -- edge) caching. I believe I tried to get ngx_pagespeed up and running when it was announced, bu…
I've found that uglifyjs does about as good a job as Closure Compiler, but waaay faster. Could be a nice speed up in deploy times for you.
Re: Small things add up: 4chan's migration to a cookieless domain
#127Earlier quoted context omitted.
Flat files on a disk == awesome
Why even write the html to disk? 4chan flushes history so aggressively I'd think you could fit all the high-traffic stuff in memory. if there's a power-blink and the posts get lost? Its 4chan.
Re: Small things add up: 4chan's migration to a cookieless domain
#128Re: Small things add up: 4chan's migration to a cookieless domain
#129Hey moot, why don't you let pass users bypass individual IP blocks? I refuse to disable my VPN, so it means I can't post any more. A shame 4chan has no way for privacy conscious users to post, especially given your support of StopWatching.us and such.
You can... you just have to shell out money for a 4chan pass :\
> "4chan Pass users may bypass ISP, IP range, and country blocks" > "Pass users cannot bypass individual (regular) IP bans."
So, if some random spammer uses the same VPN server, it gets blocked by an individual ban. This rapidly happens to all popular shared VPNs.
Re: Small things add up: 4chan's migration to a cookieless domain
#130Earlier quoted context omitted.
I've found that uglifyjs does about as good a job as Closure Compiler, but waaay faster. Could be a nice speed up in deploy times for you.
closure kicks uglify for size when compiling with advanced optimisations.