(400) Bad Request - GOOGLE! -- WHY ARE YOU EVIL?!

[cyberhex]

Over the past few days I've been experiencing a number of problems with the Google Document API that I am 100% positive was a result of changes to the Google Document API service.

 

We have customers that use our product interface with the Google Document service which has been working perfectly until a few days ago when things went down hill and now Google's "Clould" has been reduced to something totally useless,

 

BUG #1: Starting a few days ago DocumentEntry.Get() call faile when using the DocumentEntry.ID value. Switching ti SelfUri or MediaUri works.

BUG #2: Moving a DocumentEntry to a folder fails a returns "Invalid request URI" so now I cannot move entries to a folder.

BUG #3: The FolderQuery call once returned all items in a folder and now only returns 100 per request and requires requesting the next chunk

BUG #4: When uploading documents to Google these documents cannot be displayed in the web interface. A hack is to search for "*" and the documents appear.

BUG #5: GOOGLE!

 

Can someone at Google PLEASE comment on these bugs I've encountered and PLEASE let us know when these issues will be fixed. Right now I have customers that are totally screwed because of these issues.  

 

 

 

 

[Vic Fryzel]

Really?  In the future, could you choose a more appropriate subject?

On Fri, Jun 3, 2011 at 2:33 AM, cyberhex <dlevi...@gmail.com> wrote:

BUG #1: Starting a few days ago DocumentEntry.Get() call faile when using the DocumentEntry.ID value. Switching ti SelfUri or MediaUri works.

The ID URL was never usable for fetching documents.  Ever.

http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#GettingResourceAgain

 

BUG #2: Moving a DocumentEntry to a folder fails a returns "Invalid request URI" so now I cannot move entries to a folder.

Which URI are you using?  Are you using the content link of the collection?

http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#AddingToCollections

Note the /contents at the end of the URL.

 

BUG #3: The FolderQuery call once returned all items in a folder and now only returns 100 per request and requires requesting the next chunk

Since the dawn of the API, all feeds have been paginated.  This is nothing new.  I suspect that before, you were just querying folders with less than 100 entries.

You must query all the next links, until there are no more next links.

http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#GettingAllDocsAndFiles

 

BUG #4: When uploading documents to Google these documents cannot be displayed in the web interface. A hack is to search for "*" and the documents appear.

Are you uploading them with the hidden label?  There _was_ a bug that occurred on May 2 that exhibited this behavior, but it's been long fixed.

 

BUG #5: GOOGLE!

We're not a bug.

 

Can someone at Google PLEASE comment on these bugs I've encountered and PLEASE let us know when these issues will be fixed. Right now I have customers that are totally screwed because of these issues.  

I'm always happy to help anyone over bumps in their implementation, but please in the future be more civil.

Thanks,

Vic

[ChasW]

Vic,

While the tone of cyberhex is not civil, it might stem from his/her frustration at Document List not being reliable.

A bug similar to, but broader than, cyberhex bug #4 is definitely still there:

Documents uploaded using the API or even now uploaded or created in Chrome often just do not show up on the list. Sometimes they show arbitrarily. This is not the old hidden bug.

Users lose trust in data integrity if Google Docs shows them inconsistent results. They will not trust your service.

There are multiple reports of this from the just last 4 days at various levels of frustration:

from the polite:
Doc List Broken - Docs not showing in list, then some (not all) suddenly appear
http://www.google.com/support/forum/p/Google+Docs/thread?tid=33f2c573eaffffe3&hl=en

to the despair at data loss:
My spreadsheet isn't showing up in my docuemnts list. It dissapeared overnight.
http://www.google.com/support/forum/p/Google+Docs/label?lid=1222793079d1eddb

to the entertaining:
LIST OF DOCUMENTS DERANGED
http://www.google.com/support/forum/p/Google+Docs/label?lid=1222793079d1eddb

to the rude:
http://goo.gl/mod/g9na

Ignoring the problem is not going to make it go away. It needs fixing.

Perhaps it is not assigned to anyone?

[cyberhex]

Appologies for the tone/title but it did your your attention :) It would just be helpful to know when Google plans to push changes and what is being changed so third-party developers get a chance to test against these changes before customers do. Otherwise, we find these bugs when customers which is not cool.

 

fyi, it's often hard to know if the documentation is wrong or the API is wrong.

 

Apperciate your timely followup.

[Rob Wyrick]

It appears that Vic was correct.  You seem to be missing the trailing '/contents' in your POST url.
-Rob

On Fri, Jun 3, 2011 at 5:55 AM, cyberhex <dlevi...@gmail.com> wrote:

Related to the probllem moving a document to a folder here a a sample request/response where I pass through the entry id and the folder _content_ uri to move the folder. I've been using the code that does this for well over a year until recently when this started to fail. Can someone please explain why this is not working? I checked the Google documentation and my request looks ok. I have the folder _content_ id and the id of the document.  

 

http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#AddingToCollections

 

 

POST https://docs.google.com/feeds/default/private/full/folder%3A0B_WP7g_IVnkWYjhjODY0OGItODBkZi00NTgwLWIzMTItMzMxZjkxZWMzNTc0

HTTP/1.1Content-Type: application/atom+xml; charset=UTF-8
User-Agent: G-gDocumentService/GDataGAuthRequestFactory-CS-Version=1.8.0.40119
Authorization: GoogleLogin auth=<x>
GData-Version: 3.0
Host: docs.google.com
Content-Length: 290

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:gd="http://schemas.google.com/g/2005" xmlns:docs="http://schemas.google.com/docs/2007">
<id>https://docs.google.com/feeds/id/document%3A1SyWPmqVlzz_c8wYdLJQVVi-0LiNEnmloi9ft_ePp67k</id>
</entry>

 

HTTP/1.1 400 Bad Request
Content-Type: application/vnd.google.gdata.error+xml
Date: Fri, 03 Jun 2011 11:48:55 GMT
Expires: Fri, 03 Jun 2011 11:48:55 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Content-Length: 177

<errors xmlns='http://schemas.google.com/g/2005'><error><domain>GData</domain><code>invalidRequestUri</code><internalReason>Invalid request URI</internalReason></error></errors>

[Vic Fryzel]

We're currently working on a bug in which some documents are not showing up in the docs list UI that should be.

I will post updates here about its status, as well as an update when it's resolved.

As far as I can tell, this is the only bug on our end from cyberhex' original email.

@cyberhex, please let me know which issues you've yet to resolve.

@ChasW, I'll see about going through all of the forum posts today, but I think most are related to this one bug.

Thanks,

-Vic

[cyberhex]

 

I just countered a NEW bug....

 

Until about two hours ago I needed to append "/contents" to my folder paths when moving a doucment to a new folder. I found find that the folder paths now include "/contents" so now I am ending up with "/contents/contents".

 

Did someone change something related to the Content path returned for a folder? Again, this was working (magically?) earlier today and now I see "/contents" is being returned which no longer requires me to append this to the folder path when performing a select or move operation for a document.

 

 

 

[Vic Fryzel]

Are you sure you didn't change code on your end?

Nothing has changed in the API in this regard.  If you're using the content link, the content link will include /contents on the end.

-Vic

[cyberhex]

I will check this again but I am pretty sure that when I stepped through my code earlier the "/content" was not in the path. I was just using this earlier and it worked and then it stopped. I checked my code and I see "/content/content".

 

this is certainly strange.

 

[cyberhex]

First, I want to thank you for being so responsive on this issue. In the past I've posted and it takes a while to get a response.  

 

We were able to get all our issues sorted out (uploading, moving, retrieving) for documents. How do I go about getting an email notification that informs me when you plan to push changes and/or can I get a chance to test your planned changes before you push them so I can test my code and possibly let you know about any issues found that might help other developers and save you a bundle of time with support questions?

 

thanks again for your time. We are up and running again.

 

 

 

[Vic Fryzel]

We post here about major updates, and also post major updates in the release notes:

http://code.google.com/apis/documents/changelog.html

We only give advanced notice for breaking changes, but rarely give advanced notice of new features that won't break existing implementations.

Let me know if you need anything else :)

-Vic

[Tomas Odessa]

Its like a month now, and these bugs are still here.

Why are Google not fixing the bugs?

Maybe Google are not evil, but they sure do not care about bug fixes.

[Ali Afshar]

Hi Tomas,

Sorry about this, but I am not sure exactly what you mean. Cyberhex
said: "We were able to get all our issues sorted out (uploading,
moving, retrieving) for documents." so I am not sure which bugs you
are referring to.

We certainly do very much care about fixing bugs and providing the
best possible service to our customers.

Regards

--
Ali Afshar | @aliafshar | Google Developer Relations