That's definitely a valid point, and I understand how it would defeat caching. However, I believe using a hash for the callback name would make it impossible to properly deal with two requests to the same URL, because there would be no way to distinguish which AsyncCallback should get which response. This could lead to very difficult-to-debug errors.
It's not immediately obvious to me that there's a way to deal with this correctly in the general case (though ideas are of course welcome). It might be worth considering to allow the user to name the callback explicitly, but it would have to come with dire warnings about making multiple overlapping requests with the same callback name. Thoughts? On Fri, Mar 12, 2010 at 3:48 PM, Frank <frank.man...@yahoo.com> wrote: > I had a look at JsonpRequest and JsonpRequestBuilder provided by GWT > 2.0 for cross domain HTTP requests. Very nice, worked right away. > > However, there is one serious flaw... > > Like many other JSONP implementations, GWT's JsonRequest generates a > unique callback name for each single jsonp request containing a serial > number (e.g., __gwt_jsonp__.I1.onSuccess, __gwt_jsonp__.I2.onSuccess, > and so on). This callback name is appended to the URI of the GET > request, e.g., > http://service.whatsoever.com/book/12345678?callback=__gwt_jsonp__.I37.onSuccess > . > > A response header such as "Cache-Control: public, max-age=..." telling > the browser to cache the resource, will not have any effect because > the URI was skewed. Getting one and the same resource (e.g., /book/ > 12345678) with many different URIs makes browser caching through Cache- > Control impossible. > > My proposal for GWT's JsonRequest is to provide an alternative > strategy for generating callback names. If you use a hash value of the > URI rather than a serial number, browser caching through Cache-Control > would work. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
