Thanks Jesse for replying. I've created a patch for this specific issue, but when looking at this further, I see that there are additional inconsistencies with the handling if the authorization is not NONE.
If a GET method is requested, and Authorization is not NONE, and there is no refresh interval specified, it is sent as a POST request w/ no refresh, resulting in the server caching it for the default (3600s). If a GET method is requested, and Authorization is not NONE, and there is a refresh interval specified, then it is sent as a GET including the refresh interval., and would result in caching at both browser and server. In the makeRequest method, there is logic & comments that would seem to imply that authenticated requests should not be cached. It seems to me that requests with authentication should always be issued as a POST from the browser, but a refresh interval should be passed if specified. brian From: "Ciancetta, Jesse E." <[email protected]> To: "[email protected]" <[email protected]>, Date: 02/01/2012 06:51 AM Subject: RE: makeRequest with 0 refresh interval >-----Original Message----- >From: Brian Lillie [mailto:[email protected]] >Sent: Tuesday, January 31, 2012 4:52 PM >To: [email protected] >Subject: makeRequest with 0 refresh interval > > >There seems to me to be a mismatch in expectations between gadget and >server if the makeRequest REFRESH param is set to 0, resulting in incorrect >caching of the request on the server. > >If a gadget uses makeRequest and sets the REFRESH param = 0, then the >request is issued as a POST to the server, and refresh parameter is not >passed to the server. >For any other REFRESH param value, the refresh interval is set as a >parameter. > >The server looks only for the refresh parameter, and doesn't care about the >request style (GET vs POST) so the content is cached on the server for the >default (3600s) time period. > >Is the code incorrect ? or is my interpretation of refresh = 0 incorrect ? I think the code is incorrect. We've actually noticed this in our deployments too -- I've been meaning to chase it down and fix it for quite a while but just haven't gotten around to it. It looks like there's an open JIRA ticket for it too: https://issues.apache.org/jira/browse/SHINDIG-1450 If anyone has time to submit a patch for it I'd be happy to review/commit it -- otherwise I can try to fix it when I find some time. >brian >
