summarized:
292 karma · joined March 24, 2008
http://code.google.com/p/browsersec/wiki/Part3#Microsoft_Int...
http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_pag...
Eventually you might also find that you can determine the average # of views of your comment purely based on the location of it on the page, in which case the javascript tracking would no longer be necessary. Although it's also possible that the characteristics of comment viewing are too complex to be able to simplify it to that.
Also, maybe instead of a fixed score required to be orange, take a distribution of all users and only make the top X percent qualify.
Whenever the ajax search is performed an invisible iframe is loaded at: http://google.com/search?q=search+term&donothing=true.
The donothing=true tells Google's webserver to perform no actual query and return a blank page. This should happen extremely quickly. (It could be performed after the ajax results have been fully loaded as to not affect response time)
Then when a user clicks a search result, Google does a javascript redirect from the iframe (use javascript to add a new <script> tag with a window.top.location= in it) and you get a referer just like you would before... with a negligible performance hit.
Why did his thumb get caught in the conveyor? Because he was chasing his bag, which was on a running conveyor.
Why did he chase his bag? Because he placed his bag on the conveyor, but it then turned-on by surprise
Why didn't he hit the off button on the conveyor instead of chasing it? Because he wans't near the off button?
Why don't we have multiple off buttons so you're never far from one? That's expensive, let's buy some tables instead.
How much would you be willing to pay for a solution to this?
except you have an extra xml tag at the end
It's true most headers don't change. One I can think of that usually changes between resource types is Accept. Usually it will be slightly different between <img> <script> <link> and <iframe>, but this probably wouldn't make much of a difference if you allow only to send changed headers. I'd be curious to see how much bandwidth you save with this. You also might want to allow for header removal as you do header change. I can't think of a scenario where not removing a header would cause a problem, but there could potentially be one.
For the gzip as a whole instead of per request, there's one reason I can't see many browsers taking advantage of that. Most browsers will make requests like, write request, read response, write request, read response. Instead of write, write, write, read, read, read. So I'm not sure how you could unzip everything together unless you wait to display the items till the entire connection is finished. Also, this would require the client to give an indication when it is done writing requests to the stream, so that all the data can be fetched from the server and then zipped together. Which would require a much bigger change to the protocol.
Is there anything I'm missing?
If you are typing a url into your browser's location bar, you aren't going to assume google.com will have it.
Perhaps the dumbest thing of all is commenters who don't actually read up before posting comments like this particular one.
http://www.noiseandhealth.org/article.asp?issn=1463-1741;yea...
example: i48u.com, o440.com, u0-0.com, etc...