由于众所周知的原因，一些短地址服务不能访问，如bit.ly。如果在不翻Wall的情况下，有些网站提供这种还原服务，如http://untr.im，因此可以利用这个网站的api实现bit.ly解析。
如果使用Javascript代码访问，可以用下面的代码(untrim函数)：
function untrim(url){
var current = location.href;
var base_url = "http://untr.im/api/ajax/api"
var xmlHttpReq;
var result;
xmlHttpReq = new XMLHttpRequest();
xmlHttpReq.onreadystatechange = function(){
if(xmlHttpReq.readyState == 4){
result = xmlHttpReq.responseText;
}else{
//alert(xmlHttpReq.readyState);
}
};
xmlHttpReq.open("POST", base_url, false);
xmlHttpReq.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xmlHttpReq.send("url="+url);
return getUrl(result);
}
function getUrl(url){
if(url.indexOf("<a href=") == url.lastIndexOf("<a href=")){
return "";
}
url = url.substr(url.lastIndexOf("<a href=") + 9);
url = url.substr(0, url.indexOf('"'));
return url;
}
还有这里（似乎需要翻墙）也有所介绍。
另外如果是命令行，可以通过这个方法获得。
Google最近发布了pubsubhubbub协议，看上去挺简单，倒解决了我多年来关于RSS的疑惑。本来我一直以为RSS订阅是有显示的更新提示机制的，在挖掘了一些文档和实现后，发现只是简单的poll，不由得为其效率担心。好在现在有很多在线订阅器，减少了部分流量，不然很难想象一般的小站怎么能撑得住大量用户的轮询。但这么poll下去也不是个办法，效率还是不行。Google发布的pubsubhubbub协议就是为了解决这个问题而提出的，是个20%工作时间的项目。
下面的简介翻译自项目主页。
(pubsubhubbub)是一个简单的、开放的、服务器对服务器的、基于web做hook（订阅）的发布/订阅协议，作为ATOM和RSS的扩展。
支持pubsubhubbub协议的服务器，在一个它们感兴趣的话题（feed URL）更新时，可以得到近乎实时的通知（通过webhook回调）。
协议大体上是这样：
- 一个feed URL（话题）在它的ATOM或者RSS的XML文件里，通过<link rel=”hub” … >声明它的hub服务器。服务器可能由发布者运营，也可能是一个所有人都能使用的社区hub（支持ATOM和RSS的feed）。（APPSPOT可能被墙，这里推荐另一个实现superfeedr）
- 订阅者（对某个话题感兴趣的服务器）一开始像往常那样取得话题的ATOM。如果在ATOM文件里声明了hub信息，订阅者就可以跳过痛苦的、重复的URL轮询，转而在feed的hub上注册并订阅该话题的更新。
- 订阅者在声明的hub上订阅话题的URL。
- 当发布者更新话题的URL时，发布者的应用会告诉hub说有一个更新。
- hub得到更新的内容并把更新内容向该条目的订阅者进行广播。
协议本身是去中心化且自由的。没有任何公司处于控制的核心地位。任何人都可以运营一个hub、ping（发布）更新或者通过hub订阅更新。
作为起步，我们提供了一个hub的一个开源参考实现（协议中最难的部分），运行在GAE上，所有人都可以用（还要看某墙的脸色）。
Recently I came across a tricky problem about browser caching. We are working on an SaaS web project and users are identified by login names. Homepage can be viewed after login and is cache by cache directives. So if 2 accounts belong to different tenants log on the same computer without cache clearing, the second user is probably to see the wrong homepage (homepage of another tenant). This problem appears on Firefox and Chrome, but not on IE.
Then I google and found this on stackoverflow:
http://stackoverflow.com/questions/398068/ie-302-redirect-no-cache-header-problem
A quirk of IE is that when you redirect, the no-cache headers are re-added to the redirected request. Hence, in your case, your redirected request also sends the “no-cache” request header carried over from the POST request.
This explains why the problem doesn’t show on IE. The no-cache header will force the server to return the correct homepage, instead of 304 response code indicating using client-side cache.
There are also several differences about caching behavior between IE and Firefox. Check this:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
I debug the problem for nearly half of this afternoon. Here’s the description something who encountered the same problem wrote on stackoverflow:
http://stackoverflow.com/questions/811596/why-does-dojo-grid-need-a-name-column-in-the-json-data-source/
In brief, if a json data source without a ‘name’ column is provided to a dojo grid, the grid won’t show the content but a row full with question marks.
So I dig into the source code and found that the grid would perform a query with ‘{name : ‘*’}’ by default. So the most simple workaround is to add an query attribute to the <table> element, making it:
<table query=”{ID:’*'}” …>
BTW, the code lies in ‘dojox/grid/compat/_data/model.js’
最近评论