Hi Elliott,
> So if I'm understanding you correctly, then by adding in "
> service.RequestFactory.MethodOverride = true;" to my code, I basically send
> delete requests using an HTTP POST instead?
Yes, it does a POST with a specific header to say that it's actually
doing a DELETE.
> And by doing a POST instead to perform a delete action, I shouldn't run into
> this 302 redirect error? I
> have this feeling that I'm not understanding you correctly.
No, the redirect will still occur (and is not considered an error).
It is part of the session handling mechanism for the Calendar data
API. As Frank pointed out, it is handled automatically in the .NET
client library. I pointed you to the KB article to give you more
information on how it works, which is helpful to know when dealing
with it via CURL. However, all of this (redirects, session id
handling, etc) should be handled by the .NET client library. Sorry
for any confusion.
> Perhaps you mistook the
> RequestFactory class for the GDataGAuthRequestFactory instead of the
> GDataRequestFactory class?
Yes, good catch. Sorry about that-- Frank's code in his post his a
better way to handle this, as it does the appropriate casting:
GDataGAuthRequestFactory authFactory = this.factory as
GDataGAuthRequestFactory;
authFactory.MethodOverride = true;
> Thanks again!
No problem. Basically -- the problem you're experiencing shouldn't
happen, and I've never seen it occur in the past. The CURL test was
just to ensure that nothing was wrong with your actual calendar
account/data. I was then trying to make your .NET environment as much
like the CURL environment as possible by asking you to set the
methodOverride flag-- as the CURL test doesn't use the actual HTTP
DELETE method, but rather the POST method with the header-- just to
rule that out as a problem.
The next part of the investigation, as Frank mentioned, would probably
be to do a packet capture-- though if you wanted to do that, you'd
probably want to use a test account and make sure no other activity is
going on at the time that you do it (for privacy/security purposes).
Basically, you can install Ethereal/Wireshark (if it isn't installed
already on your Linux box), and go to 'Capture', 'Interfaces', choose
the appropriate interface and click 'Start'. This has to be done as
root privileges (probably using sudo) to access your network traffic.
Then, run your program, hit stop in the interface for Ethereal/
Wireshark. Sort the traffic by protocol.. you should see a bunch
labeled as the HTTP protocol. Right click and say 'Follow TCP
stream'. This should give you an indication as to what is happening.
Note, the last step applies a filter-- if you want to go back looking
at all traffic, hit the 'Clear' button at the top to clear the filter.
You could also try creating a different calendar account and see if
that account works for your program (though I suspect it won't as the
CURL test worked fine)
Cheers!
-Ryan
> On 4/1/07, Ryan Boyd (Google) <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi Elliott,
>
> > That's actually not an error, but could be an indication of what's
> > happening. The Calendar data API does use redirects for the purpose of
> > handling sessions. Please see the following KB article for more
> > info:http://code.google.com/support/bin/answer.py?answer=55833&topic=10360
>
> > The only difference in the URL you were redirected to is the gsessionid
> > URL parameter. As you were able to delete the event from your calendar
> > using this URL via curl, it doesn't seem as if there is an issue with your
> > calendar account or the like-- something is happening incorrectly between
> > your code and the client lib/mono/something else.
>
> > Try doing something like the following, as is shown (in a slightly
> > different way) in the unit test cases:
> > service.RequestFactory.MethodOverride = true;
>
> > This enables using POST with the override header I wrote about earlier.
>
> > Also, look at the GDataLoggingRequestFactory -- this will provide some
> > more logging information if used in place of the normal factory object.
>
> > Cheers,
>
> > Ryan
>
> > On 4/1/07, ekun <[EMAIL PROTECTED]> wrote:
>
> > > Wow Ryan you sure know your stuff! I'm not too familiar with packet
> > > sniffing, so that's on my next list of things to become familiar with,
> > > but I
> > > may not need that yet because your scripts appear to have found the
> > > problem. Even with this though, I'm still not sure what the remedy
> > > is.
> > > Here's what I get back on the command line:
>
> > > ----------------------------------
> > > ./gdata_calendar_delete.sh [EMAIL PROTECTED] ****
>
> > > http://www.google.com/calendar/feeds/[EMAIL
> > > PROTECTED]/private/full/d2m4la05l9f4kkm3h1fniu08uc/63311131585
> > > * About to connect() towww.google.comport 80
> > > * Trying 72.14.253.99.. . connected
> > > * Connected towww.google.com(72.14.253.99) port 80
> > > > POST /calendar/feeds/ehamai@
>
> > > gmail.com/private/full/d2m4la05l9f4kkm3h1fniu08uc/63311131585 HTTP/1.1
> > > > User-Agent: curl/7.15.4 (i486-pc-linux-gnu) libcurl/7.15.4
> > > OpenSSL/0.9.8b
>
> > > zlib/1.1.4 libidn/0.6.3
> > > > Host:www.google.com
> > > > Accept: */*
> > > > Content-Type: application/atom+xml
> > > > Authorization: GoogleLogin
>
> > > auth=***
> > > > X-HTTP-Method-Override: DELETE
> > > > Content-Length: 0
>
> > > < HTTP/1.1 302 Moved Temporarily
> > > < Set-Cookie: S=calendar=4ZPpMUDOYVA
> > > < Location:
> > > http://www.google.com/calendar/feeds/[EMAIL
> > > PROTECTED]/private/full/d2m4la05l9f4kkm3h1fniu08uc/63311131585?gsessionid=4
> > > ZPpMUDOYVA
>
> > > < Cache-control: private
> > > < Content-Length: 310
> > > < Date: Mon, 02 Apr 2007 02:44:24 GMT
> > > < Content-Type: text/html
> > > < Server: GFE/1.3
> > > <HTML>
> > > <HEAD>
> > > <TITLE>Moved Temporarily</TITLE>
> > > </HEAD>
> > > <BODY BGCOLOR="#FFFFFF" TEXT="#000000">
> > > <H1>Moved Temporarily</H1>
> > > The document has moved <A HREF="
>
> > > http://www.google.com/calendar/feeds/[EMAIL
> > > PROTECTED]/private/full/d2m4la05l9f4kkm3h1fniu08uc/63311131585?gsessionid=4
> > > ZPpMUDOYVA
> > > ">here</A>.
> > > </BODY>
> > > </HTML>
> > > * Connection #0 to hostwww.google.comleft intact
> > > * Closing connection #0
> > > -------------------------------------------------------
>
> > > It looks like I'm getting a "HTTP/1.1 302 Moved Temporarily" error,
> > > although
> > > I'm not really sure why the document was moved, how I'm supposed to
> > > catch a
> > > 302 error, and how I'm supposed to get the new uri through the C#
> > > API's. I
> > > took the new address and plugged it into your script and the event
> > > finally
> > > disappeared from my Calendar! Awesome! I'm so happy that we're
> > > making
> > > progress on this. Do you have any idea why the document moved and how
> > > I
> > > should deal with this type of situation in my code? Thanks again!
>
> > > - Elliott
>
> > > On Apr 1, 6:18 pm, "Ryan Boyd (Google)" <[EMAIL PROTECTED]> wrote:
> > > > Hi Elliott,
>
> > > > Thanks for the additional information. I haven't yet tried running
> > > > the sample code under Mono/Linux, but can certainly give that a shot
> > > > and see if it could be related.
>
> > > > The .NET client library is actually developed under Mono/OS X, so I
> > > > doubt using Mono should be an issue.
>
> > > > The DELETE request is somewhat special, as it doesn't often use a
> > > > common HTTP method (as opposed to GET, POST). Are you able to do a
> > > > packet capture to analyze the requests? While the authentication is
> > > > over SSL, you should be able to see the HTTP traffic in plaintext -- I
> > > > generally use Ethereal/Wireshark for this type of thing, but you can
> > > > also use tcpdump. This may give you more information about what's
> > > > happening.
>
> > > > You can also try grabbing the 'edit url' via the AtomEntry.EditUri
> > > > property and printing it out. Using this value, you can try deleting
> > > > the event manually through curl. Following this post is the content
> > > > of 2 shell scripts which use curl. gdata_calendar_delete.sh calls
> > > > gdata_login.sh to retrieve a ClientLogin token. It then uses this
> > > > token to DELETE the event by doing a POST with a 'X-HTTP-Method-
> > > > Override: DELETE' header (a GData specific header to perform a DELETE
> > > > via a HTTP POST). Calling gdata_calendar_delete.sh is done by:
> > > > ./gdata_calendar_delete.sh <username> <password> <edit url of entry to
>
> > > > delete>
>
> > > > Happy coding,
> > > > -Ryan
>
> > > > Disclaimer: These scripts are provided for example purposes only-- I'm
> > > > not providing any guarantees as to the quality or security of these
> > > > scripts. If you are using a shared machine, your password will be
> > > > viewable in the process listing, and may also be recorded into a shell
> > > > history file. You can freely modify these as you wish.
>
> > > > gdata_login.sh
> > > > ----
> > > > #!/bin/sh
> > > > export GDATA_AUTH=`curl
> > > 2>/dev/nullhttps://www.google.com/accounts/ClientLogin
> > > > -d Email=$1 -d Passwd=$2 -d accountType=HOSTED_OR_GOOGLE -d
> > > > source=curlExample -d service=cl | grep '^Auth=' | cut -c 6-`
> > > > echo $GDATA_AUTH
>
> > > > gdata_calendar_delete.sh
> > > > ---
> > > > #!/bin/bash
> > > > export AUTH=`./gdata_login.sh $1 $2`
> > > > curl -v -d '' -H "Content-Type: application/atom+xml" -H
> > > > "Authorization: GoogleLogin auth=$AUTH" -H "X-HTTP-Method-Override:
> > > > DELETE" $3
>
> > > > On Apr 1, 4:59 pm, "ekun" <[EMAIL PROTECTED] > wrote:
>
> > > > > Hi Ryan,
>
> > > > > Thanks for the response! So to answer your questions:
>
> > > > > 1.) It's taking about 2 minutes to return
> > > > > 2.) I'm not doing anything else with my calendar nor am I running
> > > > > multiple threads.
> > > > > 3.) There shouldn't be any proxy servers between me and Google
> > > unless
> > > > > Comcast has some kind of funky configuration.
>
> > > > > I did try to catch the exception this time and this is the actual
> > > > > message that was output:
>
> > > > > "Execution of request
> > > > > failed:http://www.google.com/calendar/feeds/[EMAIL
> > > > > PROTECTED]/private/full/..
> > > ."
>
> > > > > I also wanted to mention that I'm using mono on Linux, which was
> > > > > originally giving me authentication problems because by default Mono
> > > > > blocks everything related to web requests. I got past that problem
> > > by
> > > > > using the mozroots.exe program to add all Mozilla certificates to
> > > Mono
> > > > > (http://www.mono-project.com/FAQ:_Security), which allows me to
> > > > > authenticate with Google, query events, and create events. I
> > > figured
> > > > > that if I could get that far, then deleting an event shouldn't be a
> > > > > problem, but perhaps mono doesn't like me sending a feed request to
> > > > > that specific event uri? That's probably not the case, but I just
> > > > > thought I'd mention it.
>
> > > > > Thanks for helping me out :)
>
> > > > > - Elliott
>
> > > > > On Apr 1, 3:32 pm, "Ryan Boyd (Google)" < [EMAIL PROTECTED]>
> > > wrote:
>
> > > > > > The good news is that it doesn't look like you're doing anything
> > > > > > fundamentally wrong :)
>
> > > > > > However, I'm not quite sure what's causing the problem you're
> > > > > > experiencing. It seems as if the client isn't getting a response
> > > back
> > > > > > from the server in a resonable period of time and is throwing an
> > > > > > exception.
>
> > > > > > A few questions:
> > > > > > 1) How long is this taking to run?
> > > > > > 2) Are you doing anything else with your calendar while this is
> > > > > > running? Ie, do you have another program running
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
