You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Richard Wallace <rw...@thewallacepack.net> on 2009/08/19 01:27:31 UTC
OAuthRequest clobbering response body
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
Re: OAuthRequest clobbering response body
Posted by Richard Wallace <rw...@thewallacepack.net>.
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<et...@google.com> wrote:
> On Tue, Aug 18, 2009 at 5:35 PM, Richard Wallace <
> rwallace@thewallacepack.net> wrote:
>
>> On Tue, Aug 18, 2009 at 4:27 PM, Richard
>> Wallace<rw...@thewallacepack.net> 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
>>
>
Re: OAuthRequest clobbering response body
Posted by Kevin Brown <et...@google.com>.
On Tue, Aug 18, 2009 at 5:35 PM, Richard Wallace <
rwallace@thewallacepack.net> wrote:
> On Tue, Aug 18, 2009 at 4:27 PM, Richard
> Wallace<rw...@thewallacepack.net> 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
>
Re: OAuthRequest clobbering response body
Posted by Richard Wallace <rw...@thewallacepack.net>.
On Tue, Aug 18, 2009 at 4:27 PM, Richard
Wallace<rw...@thewallacepack.net> 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".
Rich