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 <[email protected]> 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 <[email protected]> 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 > > >
