gauravtyagi2777 / google-gdata

Automatically exported from code.google.com/p/google-gdata
0 stars 0 forks source link

updated-min parameter not encoded when AutoPaging #600

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Have your computer's time zone set to one with a + offset from UTC, like 
Belgrade (UTC +01:00)
2. Request a list of contacts modified after a certain date, where there are 
more than 25 contacts that have been modified, while using AutoPage = true.  
This will force multiple requests/responses, as the problem only happens after 
the first request/response.
3. After the first request and response the .NET library will issue a second 
request for the next 25, this is where the problem happens, and the 
"updated-min" parameter is not URL encoded.

What is the expected output?

I expect the request to properly encode the updated-min parameter and receive 
the next 25 modified contacts from the server.

What do you see instead?

The updated-min parameter is not encoded, and when it has a + offset, this 
results in an invalid time.  The server returns a 400 error with the message: 
Invalid updated-min

What version of the product are you using?
Tested with both 1.6 and 2.1 and verified the problem exists in both versions.

On what operating system?  Windows 7

Please provide any additional information below.

The following code is used to request all the modified contacts after a certain 
time:

RequestSettings rs = new 
RequestSettings(String.Format("BeileySoftware-{0}-v{1}", 
Constants.szGSyncAppName, Constants.VERSION), username, password); 
rs.AutoPaging = true; 
ContactsRequest cr = new ContactsRequest(rs); 
ContactsQuery query = new 
ContactsQuery(ContactsQuery.CreateContactsUri("default")); 
query.ShowDeleted = true; 
query.StartDate = lastsynctime;                // lastsynctime is a valid 
DateTime 
Feed<Contact> fc = cr.Get<Contact>(query); 
foreach (Contact gcontact in fc.Entries) 
{ 
        // read gcontact info... 
} 

and here is the resulting set of 2 requests/responses:

Request 1:

GET 
http://www.google.com/m8/feeds/contacts/default/full?updated-min=2012-06-21T16%3
A59%3A17%2B02%3A00&showdeleted=true HTTP/1.1
Content-Type: application/atom+xml; charset=UTF-8
User-Agent: G-BeileySoftware-Handy Address Book Sync to 
Google-v1/GDataGAuthRequestFactory-CS-Version=1.6.0.0--IEnumerable
Authorization: GoogleLogin auth=redacted-some-long-string
GData-Version: 3.0
Host: www.google.com

Response 1:

HTTP/1.1 200 OK
Content-Type: application/atom+xml; charset=UTF-8; type=feed
Expires: Fri, 22 Jun 2012 00:02:46 GMT
Date: Fri, 22 Jun 2012 00:02:46 GMT
Cache-Control: private, max-age=0, must-revalidate, no-transform
Vary: Accept, X-GData-Authorization, GData-Version
GData-Version: 3.1
ETag: W/"CUQCR386cSt7I2A9WhJTE08."
Last-Modified: Fri, 22 Jun 2012 00:02:46 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Transfer-Encoding: chunked

1000
<?xml version='1.0' encoding...<truncated>

Request 2:

GET 
http://www.google.com/m8/feeds/contacts/myemail%40gmail.com/full?updated-min=201
2-06-21T16:59:17.000+02:00&start-index=26&max-results=25&showdeleted=true 
HTTP/1.1
Content-Type: application/atom+xml; charset=UTF-8
User-Agent: G-BeileySoftware-Handy Address Book Sync to 
Google-v1/GDataGAuthRequestFactory-CS-Version=1.6.0.0--IEnumerable
Authorization: GoogleLogin auth=redacted-some-long-string
GData-Version: 3.0
Host: www.google.com

Response 2:

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Date: Fri, 22 Jun 2012 00:02:46 GMT
Expires: Fri, 22 Jun 2012 00:02:46 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Transfer-Encoding: chunked

13
Invalid updated-min
0

You can see the first request properly encodes the updated-min parameter, but 
the 2nd request does not, thus gives an error from the server.  This only 
manifests itself as a problem when the user's time zone happens to be a 
positive offset from UTC.

I captured the above with version 1.6 of the .NET client library due to 
problems capturing HTTPS traffic under 2.1, but the problem is still happening 
in version 2.1 as well.

Thanks,
Mark

Original issue reported on code.google.com by mbei...@gmail.com on 22 Jun 2012 at 12:47

GoogleCodeExporter commented 8 years ago
This bug is over a year old...  Are there any plans to fix the bugs in the .NET 
library?  Please?

Original comment by mbei...@gmail.com on 26 Jun 2013 at 8:28

GoogleCodeExporter commented 8 years ago
I have the same issue.

Original comment by covve.gg...@gmail.com on 7 Jul 2014 at 9:12