You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Ciancetta, Jesse E." <jc...@mitre.org> on 2012/02/01 13:51:07 UTC

RE: makeRequest with 0 refresh interval

>-----Original Message-----
>From: Brian Lillie [mailto:brianlil@us.ibm.com]
>Sent: Tuesday, January 31, 2012 4:52 PM
>To: dev@shindig.apache.org
>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
>


RE: makeRequest with 0 refresh interval

Posted by Brian Lillie <br...@us.ibm.com>.
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." <jc...@mitre.org>
To:	"dev@shindig.apache.org" <de...@shindig.apache.org>,
Date:	02/01/2012 06:51 AM
Subject:	RE: makeRequest with 0 refresh interval



>-----Original Message-----
>From: Brian Lillie [mailto:brianlil@us.ibm.com]
>Sent: Tuesday, January 31, 2012 4:52 PM
>To: dev@shindig.apache.org
>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
>