*slaps forehead* Thanks!
On Mar 2, 12:49 am, "Ryan Boyd (Google)" <[EMAIL PROTECTED]> wrote: > Hi James, > > The problem is the way you're passing the URL to http.get(). URI.path does > not include the query string, so the loop continues because a gsessionid is > not provided in the URL for any of the requests (ie a request for > 'https://www.google.com/calendar/feeds/<account>' is made on each iteration) > > Try using the URI.request_url() method to get the path + '?' + query string, > and you should be all set. > > Cheers, > > -Ryan > > On 3/1/07, James H. <[EMAIL PROTECTED]> wrote: > > > > > Ryan, thanks for the pointer to the KB article. > > > I suppose I wasn't following the HTTP spec since I wasn't doing > > anything with the cookie at first. I'm definitely new to the world of > > raw HTTP. I'll know better next time. > > > > The only case where I've seen redirects as you describe was the result > > of > > > sending conflicting values -- IE a request was sent with a cookie > > specifying > > > a session id of ABC, but the gsessionid URL param specified a value of > > DEF > > > (for instance). There was a bug in the cookie handling of the Java > > client > > > library which caused this type of redirect loop if the session ID was > > > changed (primarily due to requesting a calendar meta-feed)-- it has > > since > > > been resolved. > > > > If the case you found is different, please let me know and we'll work on > > > resolving it. > > > I found this to be different. It doesn't look like the gsessionid in > > the URL does anything. I checked the value of the 'S' cookie against > > the gsessionid and they're the same. > > > I know the KB article says that I can send one or the other (or both), > > but only sending the 'S' cookie value made any difference. > > > I'd be surprised if it was feed-specific, but here's the feed I was > > requesting: > >https://www.google.com/calendar/feeds/<account> > > > Here's the snippet of Ruby that I'm using to handle the redirect > > (still very raw): > > =============== > > def fetchFeed(url, authToken, cookie=nil) > > # set up the HTTPS connection > > https = createHTTPSConnection(url) > > > # add the authorization token we got from ClientLogin > > # to the headers > > headers = { "Authorization" => "GoogleLogin auth=#{authToken}"} > > > # sometimes we need to shove a session cookie in there > > # when we get HTTP 302 redirects > > headers["Cookie"]= cookie unless cookie == nil > > > return http.get(url.path, headers) > > end > > > def checkResponse(res, attempts=1) > > # Experience shows that this could easily go into an > > # infinite loop of redirects. Bail after 5 tries. > > raise "Too many connection attempts" unless attempts <= 5 > > > case res > > when Net::HTTPOK > > # .: Success :. > > return res > > > when Net::HTTPFound > > # .: Temporary Redirect :. > > # Grab the location URL and session cookie (if any) > > temp_loc = res.fetch("location") > > cookie = res.fetch("set-cookie") > > > url = URI.parse(temp_loc) > > return checkResponse(fetchFeed(url, @auth.authToken, cookie), > > attempts+1) > > > else > > ... > > =============== > > > If I comment out the line: > > headers["Cookie"]= cookie unless cookie == nil > > in fetchFeed() above, it just does an infinite loop. The 302 response > > gives a new session ID on each call. > > > Using: > > Ruby 1.8.5 > > OS X 10.4.8 (intel) > > > Hope I'm not smoking crack... > > Let me know if I can provide any more info. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
