Performing an update to a Google.GData.Calendar.EventEntry when MethodOverride is set to true, cause a GDataRequestException.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Setup a calendar application with the following setting on the 
CalendarService object:
 ((GDataGAuthRequestFactory)Service.RequestFactory).MethodOverride = true;
2. Add an EventEntry. Try to update it.
3. Get a GDataRequestException.

What is the expected output? What do you see instead?
I expect the event to be updated successfully.  I get an exception.

What version of the product are you using? On what operating system?
GData Ver: 1.4.0.2, .NET 3.5, Windows 7 & Windows XP.

Please provide any additional information below.

I'm using the MethodOverride property to bypass a firewall that will not allow 
HTTP PUT or DELETE.  Using 
this property works fine for deletes, buy when I update I get an exception.

After looking at the code I've found that the 
GDataGAuthRequest.EnsureWebRequest() method is the issue.  
It has the job of examining the MethodOverride property and then preparing the 
request by changing it to 
an HTTP POST and setting the X-Http-Method-Override header with the PUT/DELETE 
value.  One of the first 
things that the method does is remove the header and then it will later add it 
if the request is either a 
PUT or DELETE.  The problem occurs when this method is called more than one 
time before making the 
request to the server.  The second time that EnsureWebRequest() is called, the 
header will be removed and 
then it won't be added again because the first method call has changed it to a 
POST request.  You don't 
see this issue when using EventEntry.Delete() because it will only call 
EnsureWebRequest() once.  However 
EventEntry.Update() calls EnsureWebRequest() multiple times and therefore it is 
sent as a POST w/o the 
header and the web server does not recognize it.

I have fixed this by wrapping the line of code in EnsureWebRequest() that 
removes the header like so 
(sorry I'm using C# 3.0 in the fix):

    var hasHeader = http.Headers.AllKeys.Any(x => x == GoogleAuthentication.Override);
    var shouldRemove = !(hasHeader && this.factory.MethodOverride && http.Method == HttpMethods.Post);

    if (shouldRemove)
    {
        Tracing.TraceMsg("***Removing Header***");
        http.Headers.Remove(GoogleAuthentication.Override);
    }

I'm attaching "Program.cs" which will show you the problem.
Also I'll attach my modified version of "gauthrequest.cs ".  I'm not what, if 
any problems, my fix brings 
to the table, but it gets the Update() method to work.

Original issue reported on code.google.com by jas...@gmail.com on 16 Jan 2010 at 10:52

Attachments:

• gauthrequest.cs
• Program.cs

[GoogleCodeExporter]

That's a bug. And we were thinking nobody uses method override anymore :)

Original comment by fman...@gmail.com on 20 Jan 2010 at 10:23

• Changed state: Accepted

[GoogleCodeExporter]

I wish I didn't have to.  I'm pushing my Lotus Notes calendar entries from work 
up to 
Google Calendar and because I work at a large corporation I can't get an 
exception put 
in to the firewall.

Will my workaround for the issue have any side effects?  I haven't dug very 
deep into 
the issue, but I don't see why the header has to be removed at all if it's for 
the same 
request.

Original comment by jas...@gmail.com on 20 Jan 2010 at 10:36

[GoogleCodeExporter]

I moved the headers.remove inside the block that adds the header. You need to 
remove it, becuase if the 
method get's called several times, it will create invalid headers. 
Headers.Add() is not just replacing the header, 
but stringing the values together for the same key.

Can you verify that this change works for you by getting trunk and verifying.

Original comment by fman...@gmail.com on 3 Feb 2010 at 11:20

[GoogleCodeExporter]

Marking as fixed, as i asumme this works per my debugging at least.

Original comment by fman...@gmail.com on 3 Feb 2010 at 12:19

• Changed state: Fixed

[GoogleCodeExporter]

Sorry I didn't have time to check it out, but your fix sounds good.  Thanks for 
the 
help.

Original comment by jas...@gmail.com on 4 Feb 2010 at 10:32