Oh awesome! I was looking at the wrong branch of our Shindig code. Our production stuff is 1.0-incubating with some backports and I was looking at that instead of the actual Shindig trunk. This is indeed fixed on trunk and I'll be backporting that change to our version. Phew, that's a relief. Thanks.
Rich On Tue, Aug 18, 2009 at 8:36 PM, Kevin Brown<[email protected]> wrote: > On Tue, Aug 18, 2009 at 5:35 PM, Richard Wallace < > [email protected]> wrote: > >> On Tue, Aug 18, 2009 at 4:27 PM, Richard >> Wallace<[email protected]> wrote: >> > Hello, >> > >> > I've got a situation where a request to an OAuth protected resource is >> > generating a 400 response and populating the body of the response with >> > additional details. But, when OAuthRequest sees the 400 response >> > status code it decides to go ahead and ignore the body of the response >> > from the service provider and replace it with it's own. So, I have 2 >> > questsions: >> > >> > 1) Why would it ever need to do that? 401 and 403 responses that are >> > OAuth specific are handled in the fetchData() method with the >> > checkForProtocolProblem(response) call. If the response is not an >> > OAuth error, why would Shindig need to replace the actual response >> > body with one of it's own creation or do any extra work at all? >> > >> > 2) Is there a way to disable this behaviour? >> > >> > Thanks, >> > Rich >> > >> >> As a bit of a follow-up. I tried eliminating the sending of the >> request trace when it's not an OAuth error and found that the JSON >> body value still isn't being populated with the content of the >> original response. Looking at MakeRequestHandler, it only sets the >> body value if the response was a 200! This is not good because it is >> totally valid, and expected, that web services will send entities when >> the response status code is something like "201 Created", "400 Bad >> Request", and "409 Conflict". > > > Are you using the PHP or java code? This issue was fixed in the java code > almost 3 months ago, so it should have even been covered in the last > release. > > >> >> >> Rich >> >
