You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by David Boyer <ma...@gmail.com> on 2009/09/24 19:47:49 UTC
MakeRequestHandler.BAD_HEADERS... is killing our REST Service calls
Make Request strips a number of headers including Accept from an
outgoing makeRequest on it's way to the target server. We have data
that can comeback as JSON or as XML, but the default (no Accept)
header is xml. What gives. We add ContentType.JSON to the
makeRequest, and add params[gadgets.io.RequestParameters.HEADERS] = {
"accept": "text/json" } to the request params, but of course the
buildHttpRequest in MakeRequestHandler prevents the Accept header from
going through. MakeRequestHandler.BAD_HEADERS...
We need a solution that works, here.
I've searched the mailing list, and I can't see any discussion of
Accept is being throttled. If you are going to strip the Accept
header, then I had expected that the ContentType.JSON setting in
makeRequest would somehow translate into an Accept header being added
by the MakeRequestHandler, but it's not.
--
David S Boyer
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: MakeRequestHandler.BAD_HEADERS... is killing our REST Service calls
Posted by Adam Archer <ag...@ca.ibm.com>.
Thanks Kevin. I've submitted bug 1181.
https://issues.apache.org/jira/browse/SHINDIG-1181
Adam Archer
Jazz Developer
IBM Toronto Lab
From:
Kevin Brown <et...@google.com>
To:
shindig-dev@incubator.apache.org
Date:
09/24/2009 08:37 PM
Subject:
Re: MakeRequestHandler.BAD_HEADERS... is killing our REST Service calls
I don't recall why accept was dropped (probably overzealous filtering). It
probably hasn't come up before because most people don't seem to actually
use HTTP header semantics. You should file a bug for this.
On Thu, Sep 24, 2009 at 10:47 AM, David Boyer <ma...@gmail.com> wrote:
> Make Request strips a number of headers including Accept from an
> outgoing makeRequest on it's way to the target server. We have data
> that can comeback as JSON or as XML, but the default (no Accept)
> header is xml. What gives. We add ContentType.JSON to the
> makeRequest, and add params[gadgets.io.RequestParameters.HEADERS] = {
> "accept": "text/json" } to the request params, but of course the
> buildHttpRequest in MakeRequestHandler prevents the Accept header from
> going through. MakeRequestHandler.BAD_HEADERS...
>
> We need a solution that works, here.
>
> I've searched the mailing list, and I can't see any discussion of
> Accept is being throttled. If you are going to strip the Accept
> header, then I had expected that the ContentType.JSON setting in
> makeRequest would somehow translate into an Accept header being added
> by the MakeRequestHandler, but it's not.
>
> --
> David S Boyer
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>
Re: MakeRequestHandler.BAD_HEADERS... is killing our REST Service
calls
Posted by Arne Roomann-Kurrik <ku...@google.com>.
Duh, I could've just looked at the Java source.
~Arne
On Thu, Sep 24, 2009 at 6:20 PM, Arne Roomann-Kurrik <ku...@google.com>wrote:
> It would be good to list the headers which Shindig allows for outgoing and
> incoming makeRequest calls (or make this configurable?). The makeRequest
> handler in PHP could benefit from such a list.
>
> ~Arne
>
>
>
> On Thu, Sep 24, 2009 at 5:36 PM, Kevin Brown <et...@google.com> wrote:
>
>> I don't recall why accept was dropped (probably overzealous filtering). It
>> probably hasn't come up before because most people don't seem to actually
>> use HTTP header semantics. You should file a bug for this.
>>
>> On Thu, Sep 24, 2009 at 10:47 AM, David Boyer <ma...@gmail.com> wrote:
>>
>> > Make Request strips a number of headers including Accept from an
>> > outgoing makeRequest on it's way to the target server. We have data
>> > that can comeback as JSON or as XML, but the default (no Accept)
>> > header is xml. What gives. We add ContentType.JSON to the
>> > makeRequest, and add params[gadgets.io.RequestParameters.HEADERS] = {
>> > "accept": "text/json" } to the request params, but of course the
>> > buildHttpRequest in MakeRequestHandler prevents the Accept header from
>> > going through. MakeRequestHandler.BAD_HEADERS...
>> >
>>
>> > We need a solution that works, here.
>> >
>> > I've searched the mailing list, and I can't see any discussion of
>> > Accept is being throttled. If you are going to strip the Accept
>> > header, then I had expected that the ContentType.JSON setting in
>> > makeRequest would somehow translate into an Accept header being added
>> > by the MakeRequestHandler, but it's not.
>> >
>> > --
>> > David S Boyer
>> > mangr3n@gmail.com
>> > 703.499.8728(h)
>> > 703.408.5395(m)
>> >
>>
>
>
Re: MakeRequestHandler.BAD_HEADERS... is killing our REST Service
calls
Posted by Arne Roomann-Kurrik <ku...@google.com>.
It would be good to list the headers which Shindig allows for outgoing and
incoming makeRequest calls (or make this configurable?). The makeRequest
handler in PHP could benefit from such a list.
~Arne
On Thu, Sep 24, 2009 at 5:36 PM, Kevin Brown <et...@google.com> wrote:
> I don't recall why accept was dropped (probably overzealous filtering). It
> probably hasn't come up before because most people don't seem to actually
> use HTTP header semantics. You should file a bug for this.
>
> On Thu, Sep 24, 2009 at 10:47 AM, David Boyer <ma...@gmail.com> wrote:
>
> > Make Request strips a number of headers including Accept from an
> > outgoing makeRequest on it's way to the target server. We have data
> > that can comeback as JSON or as XML, but the default (no Accept)
> > header is xml. What gives. We add ContentType.JSON to the
> > makeRequest, and add params[gadgets.io.RequestParameters.HEADERS] = {
> > "accept": "text/json" } to the request params, but of course the
> > buildHttpRequest in MakeRequestHandler prevents the Accept header from
> > going through. MakeRequestHandler.BAD_HEADERS...
> >
>
> > We need a solution that works, here.
> >
> > I've searched the mailing list, and I can't see any discussion of
> > Accept is being throttled. If you are going to strip the Accept
> > header, then I had expected that the ContentType.JSON setting in
> > makeRequest would somehow translate into an Accept header being added
> > by the MakeRequestHandler, but it's not.
> >
> > --
> > David S Boyer
> > mangr3n@gmail.com
> > 703.499.8728(h)
> > 703.408.5395(m)
> >
>
Re: MakeRequestHandler.BAD_HEADERS... is killing our REST Service
calls
Posted by Kevin Brown <et...@google.com>.
I don't recall why accept was dropped (probably overzealous filtering). It
probably hasn't come up before because most people don't seem to actually
use HTTP header semantics. You should file a bug for this.
On Thu, Sep 24, 2009 at 10:47 AM, David Boyer <ma...@gmail.com> wrote:
> Make Request strips a number of headers including Accept from an
> outgoing makeRequest on it's way to the target server. We have data
> that can comeback as JSON or as XML, but the default (no Accept)
> header is xml. What gives. We add ContentType.JSON to the
> makeRequest, and add params[gadgets.io.RequestParameters.HEADERS] = {
> "accept": "text/json" } to the request params, but of course the
> buildHttpRequest in MakeRequestHandler prevents the Accept header from
> going through. MakeRequestHandler.BAD_HEADERS...
>
> We need a solution that works, here.
>
> I've searched the mailing list, and I can't see any discussion of
> Accept is being throttled. If you are going to strip the Accept
> header, then I had expected that the ContentType.JSON setting in
> makeRequest would somehow translate into an Accept header being added
> by the MakeRequestHandler, but it's not.
>
> --
> David S Boyer
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>