Ow that is some way back, but if memory serves me correctly this was fixed, php shindig trunk should deal with it correctly, i'll make a note to double check though, or if you have a moment I would love to hear if it's working for you!
On Fri, Jul 10, 2009 at 10:06 PM, Michael Gold <mgol...@gmail.com> wrote: > Chris, > > Any update on support in Shindig PHP for > gadgets.io.RequestParameters.HEADERS? > > thanks! > Michael > On Sat, Mar 21, 2009 at 12:52 PM, Chris Chabot <chab...@google.com> wrote: > > > Hey Michael, > > > > Currently PHP Shindig doesn't support > gadgets.io.RequestParameters.HEADERS > > I'm afraid, I completely overlooked that bit of the spec and your the > first > > to notice, so thanks for pointing that out so we can go fix it :) > > > > Pan Jie is digging around in the RemoteContent classes currently > > (refactoring & adding support for limited cache invalidation, etc), Pan > is > > this something you could easily pick up and fix while your reworking > those > > classes? > > > > -- Chris > > > > On Fri, Mar 20, 2009 at 2:04 AM, Michael Gold <mgol...@gmail.com> wrote: > > > > > I was working with makeRequest and Shindig PHP, and noticed that the > http > > > request headers I sent using gadgets.io.RequestParameters.HEADERS were > > > being > > > dropped. > > > (My test: I pointed makeRequest at a quick and dirty script that > returns > > > the > > > entire contents of $_SERVER and $_REQUEST in a JSON object. No headers > > were > > > returned, plus Firebug and Fiddler reveal that, at least in the Post > from > > > browser-to-server, the 'headers' parameter is indeed being sent.) > > > > > > At first, I thought I had found a clean explanation - I was sending an > > > Authorization header, and I had read that certain OpenSocial containers > > > restrict the Authorization header (and some other headers as well) for > > > security reasons. > > > > > > Fair enough. > > > > > > So I created my very own X-header. (X-Mikey: foo) > > > > > > But X-Mikey didn't seem to fly either. > > > > > > This got me curious, so I fired up a debugger and stepped through the > > > makeRequest process. > > > > > > Here is what I discovered so far. Once the modules load, the $headers > > > variable does seem to make it into Shindig. It even goes so far as to > > > explode it into an array. But once that occurs I didn't see anything > > after > > > that except $headers = false. > > > > > > So far I found reference to $headers in: > > > > > > + src/common/sample/BasicRemoteContentFetcher.php - home of curl, also > > home > > > to the $disallowedHeaders array which does include a number of headers, > > but > > > Authorization was not there. > > > + src/gadgets/SigningFetcher.php - here I saw a function called > > sanitize() > > > that seems to exclude the headers from the OAuth signature calculation, > > but > > > I was unsure if sanitize() removes the headers from the request > > altogether > > > > > > + src/common/RemoteContentRequest.php > > > > > > + src/gadgets/MakeRequestHandler.php > > > > > > I think if I stepped through it in the debugger a couple more times I'd > > be > > > able to see more clearly and perhaps put my finger on where the > > disconnect > > > is. (That or come to the realization that the disconnect is me!) > > > > > > Since the code is already familar territory to many here I thought I'd > > ask: > > > Are the missing request headers a known issue? (Should I keep digging?) > > > Does Shindig not support makeRequest's > > > gadgets.io.RequestParameters.HEADERS ? > > > > > > Thanks in advance, > > > Michael > > > > > >
