chaitanyabm / gdata-ruby-util

Automatically exported from code.google.com/p/gdata-ruby-util
Apache License 2.0
0 stars 0 forks source link

Calendars still experience 302 errors #4

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
require 'gdata'

>> client = GData::Client::Calendar.new
>> client.clientlogin( username, password )
>> client.get( "http://www.google.com/calendar/feeds/default/allcalendars/full")

#=>  

#<GData::HTTP::Response:0x25cdf80 @status_code=302, @headers={"cache-
control"=>"private, max-age=0", "connection"=>"close", "expires"=>"Sun, 03 May 
2009 
18:53:53 GMT", "x-content-type-options"=>"nosniff", "date"=>"Sun, 03 May 2009 
18:53:53 
GMT", "content-type"=>"text/html; charset=UTF-8", "server"=>"GFE/2.0", "content-
length"=>"240", 
"location"=>"https://www.google.com/calendar/feeds/default/allcalendars"}, 
body"<HTML>\n<HEAD>\n<TITLE>Moved Temporarily</TITLE>\n</HEAD>\n<BODY 
BGCOLOR="#FFFFFF" TEXT="#000000">\n<H1>Moved Temporarily</H1>\nThe document has 
moved <A 
HREF="https://www.google.com/calendar/feeds/default/allcalendars">here</A>.\n</B
ODY>\n
</HTML>\n"

I am using the latest gem. 

Original issue reported on code.google.com by this.rya...@gmail.com on 3 May 2009 at 6:58

GoogleCodeExporter commented 8 years ago
Again, I had to do add a line to GData::Client::Calendar.make_request. 

      def make_request(method, url, body = '', retries = 4)
        response = super(method, url, body)
        if response.status_code == 302 and retries > 0
          @session_cookie = response.headers['set-cookie']
          # I added this guy here so that the library would work.
          url = response.body.match(/<a href=\"([^>]+)\">/i)[1]
          return self.make_request(method, url, body, 
            retries - 1)
        else
          return response
        end
      end

Original comment by this.rya...@gmail.com on 3 May 2009 at 7:07

GoogleCodeExporter commented 8 years ago
I am not able to reproduce your problem. I have a unit test that passes 
perfectly:

http://code.google.com/p/gdata-ruby-util/source/browse/trunk/test/tc_gdata_clien
t_calendar.rb

Does this test fail for you?

Also you shouldn't have to extract a link from the response if you use the 
session
cookie. What version of Ruby are you using? I think Net::HTTP behaved strangely 
in
some older versions. I'm on ruby 1.8.6 (2008-03-03 patchlevel 114) 
[universal-darwin9.0]

Original comment by jfis...@youtube.com on 4 May 2009 at 6:40

GoogleCodeExporter commented 8 years ago

Original comment by jfis...@youtube.com on 6 May 2009 at 5:10

GoogleCodeExporter commented 8 years ago
wow. sorry for the delayed response. I have tested the code on two different 
machines and each time that test 
fails. 

1) ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]

2) ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

each machine returned the following test result: 

Loaded suite tc_gdata_client_calendar
Started
F
Finished in 1.156392 seconds.

  1) Failure:
test_get_all_calendars(TC_GData_Client_Calendar) 
[tc_gdata_client_calendar.rb:29]:
Must not be a redirect.
<200> expected but was
<302>.

Original comment by this.rya...@gmail.com on 24 Jun 2009 at 4:50

GoogleCodeExporter commented 8 years ago
I have a new update. I have been testing this plugin using a google apps 
account. I updated my credentials using 
my personal @gmail.com account and the tests passed with no issues. What could 
be causing the problems 
when using a google apps account? 

Original comment by this.rya...@gmail.com on 28 Jun 2009 at 12:25

GoogleCodeExporter commented 8 years ago
Just encountered this problem (feed request fails because of redirect to https) 
also,
and managed to figure out the cause and a solution.
This happens when the account belongs to a Google App, under a domain that has 
been
declared SSL enabled (under the Domain Settings page, when managing the Google 
Apps).

The fix that was used for the session cookin in GData 1.0.1 is not enough to 
handle
redirects, since it disregards the returned url (the redirect_to).
I wouldn't use parsing of the response body, like this.ryansmith, but instead 
use the
'location' header:
url = response.headers['location']

I predict that this might occur for other Google services under the same
circumstances (SSL domain), but I haven't checked for it (yet).

I recommend this be fixed in the next GData version.

Original comment by rono.mu...@gmail.com on 14 Jul 2009 at 4:18