Hey Doug, What's the HTTP response code on the first request that returns the oauthApprovalUrl? From what I can tell, if the cachedResponse has a status code >=400, we won't use it as the staleResponse in the case of a 500 error on the subsequent request.
Regarding not caching your service calls at all, you can use the "nocache" in the render parameters but that will result in ALL calls bypassing the cache and not just your particular service calls. Regards, -Stanton On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas <davi...@oclc.org> wrote: > Hi Guys, > > It’s Doug Davies. Been a while since I’ve been active on the shindig mail > list. We are getting back into our shindig implementation. We have > upgraded our container to the latest release. > > We are having an issue that I think I brought up in the past, but I can’t > find the thread in the archives. > > Here’s the scenario… > > We have an oauth2 gadget that makes a request to one of our internal > services. That service happens to return a 500 error for a bad parameter > that gets passed in (I know probably not the right response, but I don’t > have control over that). When it makes the first call to the service it > gets back an oauthApprovalUrl like it should. I then present the UI for > that link to initiate the oauth2 handshake. Once it’s done the gadget then > makes the request again, this time with an access token. However, since > the service returns a 500 it seems the DefaultRequestPipeline code uses the > “staleResponse” (the last successful response that had the oauthApprovalUrl > in it) and so I get into an infinite loop. > > I tried setting > > params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0; > > but that doesn’t seem to matter. Ideas on how to solve this? Even if a > 500 error isn’t the right response to be returning, it still seems like I’d > want to detect that this happened rather than the response looking like the > oauth flow needs to be initiated again. > > In fact, I don’t know that I want any of my service calls being cached. > > Thanks, > Doug Davies > > >
