Sounds technically like a grey area to me, but at the same time your
approach seems reasonable.

"nocache" in the rendering URL doesn't strictly mean that "nocache" should
be appended to all downstream requests -- at least, AFAIK that's not spec'd
anywhere.

This said, what you've implemented is more intuitive to the user. I'd be in
favor of including it (as well as corresponding behavior in proxy URLs).

--j

On Mon, Mar 14, 2011 at 12:39 PM, Cheler, Vinay (LNG-DAY) <
[email protected]> wrote:

> Hi,
>
> We are using Shindig 2.0.0, and one of the requirements is to disable
> caching when using makeRequest API. So we appended nocache=1 to the url
> before invoking that API, but we noticed it was still caching the response.
>
> Digging thru the code I found that  MakeRequestHandler.java is looking for
> a request parameter called "nocache" :
>
>
> req.setIgnoreCache("1".equals(request.getParameter(Param.NO_CACHE.getKey())));
>
> However on the client side in the io.js file (part of core.io feature),
>  nocache is not being sent at all as part of the paramData in the
> makeRequest function:
>      var paramData = {
>        url: url,
>        httpMethod : httpMethod,
>        headers: gadgets.io.encodeValues(headers, false),
>        postData : params.POST_DATA || "",
>        authz : auth || "",
>        st : st || "",
>        contentType : params.CONTENT_TYPE || "TEXT",
>        numEntries : params.NUM_ENTRIES || "3",
>        getSummaries : !!params.GET_SUMMARIES,
>        signOwner : signOwner,
>        signViewer : signViewer,
>        gadget : urlParams.url,
>        container : urlParams.container || urlParams.synd || "default",
>        // should we bypass gadget spec cache (e.g. to read OAuth provider
> URLs)
>        bypassSpecCache : gadgets.util.getUrlParameters().nocache || "",
>        // nocache added by me
>        nocache : gadgets.util.getUrlParameters().nocache || "",
>        getFullHeaders : !!params.GET_FULL_HEADERS
>      };
>
> When I added "nocache" as above, it worked, meaning it did not cache the
> response.
>
> Can somebody please validate if this indeed is a bug, or did I miss
> something? Or is there any other alternative?
>
> Thanks
> Vinay
>

Reply via email to