if i had to guess i would say the visitor's request was the result of clicking a link in an email that also contained an embedded image.

I wouldn't block it unless it becomes a regular visitor.

Is the referrer Google News or Google Images by any chance? I know both have been experimenting with the data: protocol (which is what you've got there) for preview images lately, my guess is that a spider doesn't know how to deal with a data: URI and is applying the address found in a background-image for a preview to a base href generating that funky link.

That "obfuscated code" at the end is actually base64 encoded image data.

The referer was Google, not images or news. The visitor specifically wanted my website, but information about a certain animal. The next few lines in the log showed them finding the page they wanted. Then there were these two entries in the log:

67.83.122.nnn - - [25/Oct/2010:19:22:57 -0400] "GET /favicon.ico HTTP/1.1" 200 19342 "-" "Mozilla/5.0 (compatible; Google Desktop/5.9.1005.12335; [desktop.google.com...]
67.83.122.nnn - - [25/Oct/2010:19:23:09 -0400] "GET /mammals/deer/url(data:image/png;base64,obfuscated code) HTTP/1.1" 404 1889 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB6.6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; MDDC; .NET CLR 3.5.30729; .NET CLR 1.1.4322; .NET CLR 3.0.30729; .NET4.0C)"

Then there were four more entries with the same obfuscated code, then they left.
Does it have something to do with Google Desktop?

I'm leaning towards the user clicking something in an email along with phranque now. Maybe a Google Gadget.

It looks like Google Desktop is requesting your favicon to show along with maybe some widget results or something, but producing a bunk link.

I'd just wait a day or two and see if I can find it again. I can't think of anything malicious that could come of it. I think worst case scenario there's a bug in an email/RSS-feed you're sending out (but then why doesn't it happen more often?) or a bug in someone's gadget.

I had one of those yesterday as well

77.160.126.nnn - - [28/Oct/2010:21:54:26 +1300] "GET /favicon.ico HTTP/1.1" 200 1406 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; InfoPath.2; .NET4.0C)"
77.160.126.nnn - - [28/Oct/2010:21:54:29 +1300] "GET /folder/url(data:image/png;base64,iVBORw snipped) HTTP/1.1" 404 780 "http://www.example.com/folder/index.php?gen_name=&page=type&id_type=Keyword&ul=" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; Inf
77.160.126.nnn - - [28/Oct/2010:21:55:53 +1300] "GET /folder/index.php?gen_name=Key&page=ind&id=667&ul= HTTP/1.1" 200 977 "http://www.example.com/folder/index.php?gen_name=&page=type&id_keyword=Keyword&ul=" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; InfoPath.2; .NET4.0C)"

The image data was so long that the UA got truncated in the log and had no space between it and the next record.

The visitor didn't click on an e-mail link, but arrived via a Google Search.

It is looking more like a bug in IE 8 to me.

I think it might have something to do with allowing the page to be downloaded faster or more securely, in my case, images. Wikipedia has some info on Data URIs.

I saw the same request today.
The visitor from the US comes via a common search on Google.com and visits several pages like any other visitor to this site would do.
After loading the first page via the search result link there is this request for

/directory/url(data:image/png;base64,iVBORw [snip]) The [snip] is 1550 characters long !
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.6; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
with referrer http : //www.mysite.com/initialdirectory/initialpage.asp and it gets a 404 (I broke the link)

The visitor keeps browsing the site in a normal pattern, accessing different directories and a number of pages, some of which are image heavy (in number but not in size), but no base64 requests.
Only when the visitor accesses the original landing page again is the request made (three times for this visit).

Anyway, it's quite apparent to me that it has nothing to do with any purposeful intention of the visitor and as long as it gets a 404 that's fine by me.

[Edit} Thank you grandma genie, the Wiki info explains it all ;o)

I've noticed that every one of the requests are for the same:

"GET /url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADgAAAAOCAYAAAB6pd%2buAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A%2fwD%2foL2nkwAA
snip

Any ideas of a .htaccess redirect for /url or what to put in a page header to eliminate this annoying log entry? I'm wondering what all these MSIE 8 users are looking for. It must be some default setting in their browser.

Another similar strange one:

96.238.188.234 - - [01/Nov/2010:22:26:32 -0400] "GET /url(res://C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) HTTP/1.1" 302 294 "http:/[smilestopper]/www.example.com/" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6.6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

Looks like it is actually something Google related. Probably Google Toolbar (GTB6.6).
I embedded the whole thing in html (see example below), and what you then see is a picture of a question mark, a minus sign, a check box and then the small square Google logo (like the favicon) with a magnifying glass.

<html>
<head>
<body>
<img alt="Embedded Image"
src="data:image/png;base64,iVBORw0KGgo..." />

</body>
</html>

So is the Google toolbar somehow "mis-looking" for /url on web sites instead of looking locally?

I suspect that the Google Toolbar is trying to embed the image into the page being fetched and not quite doing it correctly, hence the browser then making the request for the non-existent URL.
I've filled out the "Report a Toolbar bug contact form" so they will hopefully address the issue.

I agree with Dijkgraaf. All the visitors so far who have this code in the logs are using IE8 and are from a Google search.

Well, since I don't have a directory called "url" I just added a line to .htaccess and on the site I added it I'm not seeing the errors in the access log today:

Redirect 301 /url [google.com...]

By the way, the C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) error is not just MSIE 8. I'm seeing it in IE 6 & 7 in the log.
e.g.
compatible; MSIE 7.0; Windows NT 5.1; GTB6.6; InfoPath.3; .NET4.0C; .NET4.0E
compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6.6

mistake in the redirect, "(" isn't a separator. Could use

Redirect 301 /url(data:image/ http://www.google.com/

Or,

RewriteEngine On
RewriteBase /
RewriteRule ^.*url\(data:image(.*)$ http://www.google.com/ [L,R=301]

That takes care of the problem of it looking for /url(data:image/ etc. in various sub-directories.

I discovered that rewrite and redirect didn't work. Worked on testing with a portion of the data:image string, but the entire string they're trying still produces a 404 instead of a 301 redirect apparently.

All the visitors so far who have this code in the logs are using IE8 and are from a Google search.

Check to see if all the visitors also have GTB6.6 in their UA string.

Mine do, Dijkgraaf.

Hello,
I have also received these strange requests.
The reason is as you said the GTB6.6
Try the following:
Copy the string in base64.
Paste it into [meyerweb.com...]
Click to decode and copy the output to paste in [motobit.com...]
Select "decode the data from a Base64 string (base64 decoding)" and "export to a binary file, filename:"
Put as name "google.png" and make click on "Convert the source data" Open the file and voilą!

I don't know if this is related, but if you look at the current google.com search page with the live search results and preview - do a search, and pop open the preview for a page. If you inspect the image element that is displayed in the preview, you will see that it has a src value that looks something like "data:image/jpeg;base64,/9j/[encoded text here]".

I'm not quite sure how this works within the google search page - I was mostly curious how this "data:image" src was working (appending the src value to the google hostname doesn't work because the string is too long). This page is the only location that I've found so far that discusses this...

Now I'm getting these odd requests, just like the one DantheWebMan mentioned. Here they are:
69.121.140.nnn - - [28/Nov/2010:19:31:15 -0500] "GET /store/url(res://C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) HTTP/1.1" 404 8747 "www.mywebsite.com/store/newprods1.html" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts; GTB6.6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

69.121.140.nnn - - [28/Nov/2010:19:32:55 -0500] "GET /store/url(res://C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) HTTP/1.1" 404 8747 "www.mywebsite.com/store/newprods1.html" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts; GTB6.6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

67.190.42.nn - - [28/Nov/2010:20:30:15 -0500] "GET /store/url(res://C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) HTTP/1.1" 404 8747 "www.mywebsite.com/store/newprods2.html" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6.6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30618)"

72.66.197.nnn - - [28/Nov/2010:22:32:11 -0500] "GET /store/url(res://C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) HTTP/1.1" 404 8747 "www.mywebsite.com/store/newprods3.html" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6.6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; AskTbWBV5/5.9.1.14019)"

They are all using GTB6.6.

One "url(data:image/png;base64 (etc.)" sighting here in the last hour:

Google Referer? No (no ref)
Google TB? Yes: GTB6.6
Apparently Real? Yes

Notes: Multiple images on page but "url(data:image/png;base64" appeared only once -- 30 seconds after the visitor first hit the page -- not beforehand, as would be suggested by their clicking on a Google Web Preview icon/image and then visiting the page.

Speaking of... Google Web Preview [webmasterworld.com]

@DanTheWebManSRQ: A 404 server response is proper, and methinks preferable to rewriting the pattern to anywhere (let alone to Google -- oy).

If these mystery URIs get out of hand before whatever's causing them gets fixed, I'll be tempted to suppress them in my logs because they're so danged long. (At which point I'll hope jdMorgan [webmasterworld.com] has already weighed-in:)