_NASTY BUG_ in Google AJAX Search API v1

7 views
Skip to first unread message

amattie

unread,
Mar 26, 2010, 1:50:28 PM3/26/10
to Google AJAX APIs
As of this moment, it looks like the latest version of the Google AJAX
Search API (v1) has a pretty nasty bug where it seems that it's
setting an empty image source somewhere in the JavaScript. Per
Nicholas Zakas here < http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/
>, that empty image source -- just my suspicion that it's that -- is
causing an extra page request to be made to our server and is causing
all sorts of nasty scaling issues for us as well as other bugs.

To see this bug in action, fire up Fiddler2 or Charles or whatever and
take a look at the requests for this page when using Chrome, Safari,
or IE: http://www.fatkidproductions.com/goog-ajax-search-api/broken.html

Now take a look at the requests for this page:
http://www.fatkidproductions.com/goog-ajax-search-api/working.html

Notice how in the first URL that a duplicate request is issued in
WebKit and a request to the containing dir is issued in IE? If you
take a look at the source, you'll see that the problem is definitely
caused by the Google AJAX Search API as it's the only thing on the
page.

Please fix. This is causing havoc for us right now.

amattie

unread,
Mar 26, 2010, 1:59:51 PM3/26/10
to Google AJAX APIs
Please take a look at this screenshot to see proof of these duplicate
requests: http://www.fatkidproductions.com/goog-ajax-search-api/requests-screenshot.png

The screenshot was taken with IE requesting broken.html and
working.html. Requests 1 - 4 are for broken.html. Requests 15 - 16 are
for working.html.

Again, I strongly suspect that this issue is caused by an empty src
property of an Image object somewhere in the code. I haven't debugged
it at all though as it'd just be a waste of my time and as I'm certain
it'd just be easier to find this problem by looking at the previous
commits before the deploy.

Jeremy Geerdes

unread,
Mar 26, 2010, 2:47:17 PM3/26/10
to google-ajax...@googlegroups.com
Looking at your page in both Safari and Chrome (which both use WebKit's built-in inspector), I am seeing your stray request, but I don't think it has to do with the API. Rather, I think it's that the browser is looking for a favicon.ico and finding nothing. You might use a meta tag to specify one and see if that doesn't eliminate the mysterious request (you would still see the request for the favicon, but the mystery request would be gone).

Jeremy R. Geerdes
Effective website design & development
Des Moines, IA

For more information or a project quote:
http://jgeerdes.home.mchsi.com
jrge...@gmail.com

If you're in the Des Moines, IA, area, check out Debra Heights Wesleyan Church!

> --
> You received this message because you are subscribed to the Google Groups "Google AJAX APIs" group.
> To post to this group, send email to google-ajax...@googlegroups.com.
> To unsubscribe from this group, send email to google-ajax-searc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-ajax-search-api?hl=en.
>

amattie

unread,
Mar 26, 2010, 5:47:33 PM3/26/10
to Google AJAX APIs
The browser definitely is looking for a favicon, but I really don't
think that has anything to do with the extra request to the home page.
The behavior described with this bug is exactly what Zakas described
in the empty image "src" attribute problem. Specifically:

1) In IE, an extra request is issued for the directory containing the
file.
2) In WebKit, an extra request is issued for the page hosting the
malfunctioning script or img tag.
3) In Firefox 3.6, no extra requests are issued.

You can verify this using Charles or Fiddler. Regardless, when I do
have the page with the AJAX search API on it, the second request is
issued. As soon as the AJAX search API is removed, the stray request
is never issued and our servers actually have some room breathe again
since the load practically drops by half! You can see this if you look
at the source for the two pages; the only difference between the two
is that the API search loader is commented out.

This only started happening in the last few days. I'm really hoping
that a Google engineer will take notice of it and fix it soon!

Andrew

CharlesHarrison

unread,
Mar 26, 2010, 9:47:20 PM3/26/10
to Google AJAX APIs
Yup, that figures. If you put an img tag with an empty string as src
into a browser, they all behave differently:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Generic Test Page</title>
<style type="text/css">
<!--
* { color:inherit; background-color:inherit; border-
color:inherit; }
html { color:#FFFFFF; background-color:#330000; }
-->
</style>
</head>
<body
onload="javascript:alert(document.getElementById('NullSrc').src);">
<h1>Generic Test Page</h1>
<img src="" id="NullSrc" alt="Empty image src property test"
title="Empty image src property test">
</body>
</html>

When I run this on the browsers I have available for testing, FF3
gives you the page URL, IE the directory of the page, and only Opera 9
correctly gives you an empty string. Note that, AFAICT, FF and IE are
actually *replacing* the empyty URL with the values given above.

Jeff S (Google)

unread,
Mar 27, 2010, 1:59:07 AM3/27/10
to Google AJAX APIs
Hi Andrew,

Thank you for reporting this. Would you mind filing this in our issue
tracker as well?

http://code.google.com/p/google-ajax-apis/issues/entry

I will also reply on this thread with further updates.

Thank you,

Jeff

On Mar 26, 6:47 pm, CharlesHarrison <c.e.m.harri...@macfh.co.uk>
wrote:

amattie

unread,
Mar 27, 2010, 11:20:58 AM3/27/10
to Google AJAX APIs
Thanks for the reply, Jeff. I've posted the bug to the Google Code
project you referenced.

http://code.google.com/p/google-ajax-apis/issues/detail?id=420

My apologies for the somewhat alarmist subject of this post.
Considering that it's doubling the requests to our servers, I really
just wanted a Google employee to take notice so that this didn't get
lost.

Andrew

omr

unread,
Mar 28, 2010, 3:34:31 AM3/28/10
to Google AJAX APIs
While you wait for the bug to be fixed, consider this temporary
experimental workaround to suppress the extra requests:

First, change all relative URIs to absolute URIs, throughout the
page(s) where you load the search API. Then add a BASE element
specifying a nonexistent domain.

Example:
HTML: <base href="http://nonexistent-domain.com/">
XHTML: <base href="http://nonexistent-domain.com/" />

Place that element in the HEAD section (prior to any other element
therein that refers to an external URI). Check again to make sure
that all URIs specified in the document are absolute (e.g.
"http://...").

Test the modified page(s) in Webkit, IE, and any other type of browser
where you previously observed the extra requests.

(Disclaimer: This workaround is experimental. I don't know if
specifying a bogus base might cause unwanted side-effects. In any
case, this obviously isn't the proper or intended usage of the base
element. Use this workaround entirely at your own risk, and only if
you consider it absolutely necessary to suppress the extra requests
while you wait for the API bug to be fixed.)

-- omr

CharlesHarrison

unread,
Mar 28, 2010, 8:21:00 AM3/28/10
to Google AJAX APIs
If you use a means of fetching scripts or data by dynamically
inserting script tags into the document, some versions of IE (I've
encountered it in 6 for sure) have a bug whereby this kills the
document:

http://code.jquery.com/jquery-1.4.2.js
Lines 5091-4:
"""
// Use insertBefore instead of appendChild to circumvent an IE6 bug.
// This arises when a base node is used (#2709 and #4378).
head.insertBefore( script, head.firstChild );
"""

I know that Google use dynamic script tag insertion in some of their
code, so unnecessary use of a base tag may not be advisable.

Jeff S (Google)

unread,
Apr 1, 2010, 2:17:08 AM4/1/10
to Google AJAX APIs
Hi all,

Thanks again for the issue report and for your patience with this
issue. We've made the necessary changes and you should no longer see
these additional requests. Apologies again for the inconvenience.

Happy coding,

Jeff

On Mar 28, 5:21 am, CharlesHarrison <c.e.m.harri...@macfh.co.uk>
wrote:

Reply all
Reply to author
Forward
0 new messages