SES San Jose Opens Today

We would be remiss if we didn’t mention the WebProNews contingent making the rounds of the convention. Our video staff has their cameras and mikes at the ready. As long as no one messes with managing editor Mike McDonald’s coffee, he’ll be there too.

The run-up to this edition of SES San Jose proved less dramatic than last year. Ahead of the conference, AOL Research placed thousands of search records online, creating a field day for all kinds of interested observers and lots to talk about through and beyond the conference.

The pre-conference issues this year are a little more understated, but just as interesting. Last week, Dan Thies published an overview of hacking Google by proxy. Such an attack could knock one’s site right out of the search rankings, which would be devastating to a site’s traffic.

Click fraud discussions at SES San Jose previously put search engine representatives on the dais with third-party click analysis companies for some interesting and sometimes combative dialogue.

Those two sides have been separated into a pair of consecutive sessions this year, taking place on day two. We have to hope the third-party folks will stop by the search engine’s click fraud session and lob some verbal brickbats from the audience.

Co-chairs Danny Sullivan and Chris Sherman have put together a compelling slate of presentations for SES San Jose 2007, and we’re looking forward to covering them. Stop by WebProNews through the week to catch some exclusive videos and other reports from the conference.

Google Search Results: Your SERPs At Risk

A few short days before the biggest search conference of the year, SES San Jose, we’ve learned of a story that should have people talking next week. Dan Thies claimed he has been sitting on an explosive story of Google proxy hacking for a year, and has just posted about it on his SEO Fast Start blog.

"Danny Sullivan has known nearly as long, and I suspect that his behind the scenes efforts are the reason why the major search engines all decided to publish "how to validate our spider" instructions after SES San Jose last year," Thies said.

A SEO client, Brad Fallon, with a site that Google indexed all of save the home page, set Thies looking for the reason why that page wasn’t making it into the SERPs. The client’s page had been fetched by Googlebot through a proxy, creating a duplicate content situation.

Thies’ client’s home page was being dropped by Google. Through further investigation, Theis discovered, "Someone was actively seeking out proxies and linking to them, so that Google would pick them up, and drop Brad’s home page." Fallon’s site had not been banned by Google.

To alleviate the problem, Thies opted to do the same thing bookmarking site Delicious does: reverse cloaking:

Every page Brad’s web servers deliver now has "noindex, nofollow" in the robots meta tag, unless the request comes from a validated search engine spider. A "spoofed" proxy visit from Googlebot delivers a page that won’t be indexed. A real visit from Googlebot gets the page with "noindex" removed.

The problem has been existent for more than a year, and Thies felt it was time to talk more about this issue publicly. We’re betting lots of people will do just that.

How do marketers create market research tools espousing the value of something they are not doing themselves, then market it via blog comment spam? It isn’t hard to send an email or buy a review. If their service is worth $90 a month (their current price) their marketing budget should include some money for paid search and public relations. They could at least have a blog comparing seasonal data and data from different companies the way Hitwise does.

The easiest way to show the value of your offering is to eat your own dog food. That is why ReviewMe bought a bunch of its own ads to help the site go viral at launch. There are so many ways to market ad networks or competitive research tools that there is no point creating one if the marketing strategy starts with the likes of blog comment spam and/or cold calling.

Comments

Matt Cutts Discusses Cache Crawling

Cutts’ latest blog post reviewed Bigdaddy’s crawl-caching proxy in greater depth. He even provided helpful charts to illustrate the process.

As a webmaster, one may see numerous fetches from multiple Googlebots, each of them using some bandwidth while accomplishing their appointed rounds. It makes for a more accurate Google index, but the site impact has given some webmasters fits over the bandwidth usage.

The proxy used in the Bigdaddy infrastructure works like other proxies. It handles the effort of retrieving pages from websites, and fulfills requests from the various Google crawlers. Instead of multiple spiders hitting a website, they hit the cache instead.

Cutts breaks down the crawl caching in a summary during his post (spacing added; we like Matt, but we’d really like him to enjoy the Return key a bit more often :

The essential goal of the proxy, to reduce bandwidth, seems to have worked to Google’s satisfaction. Cutts wrote that “it was working so smoothly that I didn’t know it was live.”

—

Add to | DiggThis | Yahoo! My Web | PreFound.com

Bookmark WebProNews:

David Utter is a staff writer for WebProNews covering technology and business.

The statement outlines compensation for select executives, including William Clay Ford, Jr., chairman and chief executive officer.

Compensation of Ford executives for 2004 generally consisted of salary, stock-based awards and bonuses.

Compensation details found in the 2005 proxy statement include:

William Clay Ford, Jr., chairman and CEO, received no cash salary in 2004. In lieu of a cash salary equivalent to $1.5 million, he was awarded 103,882 shares of restricted common stock, tying his compensation to the long- term performance of the Company. He was awarded a 2004 bonus in the form of 841,008 shares of restricted common stock and restricted stock equivalents with a fair market value of approximately $10.5 million at the time of grant. In lieu of other long-term compensation, he also received a stock option grant covering 1,587,301 shares. These options have a strike price of $16.49 and vest over a three year period. Mr. Ford also exercised stock options covering 1,410,404 shares, realizing a value of $5.3 million, at the same time retaining the acquired shares. In addition, he received other compensation totaling $266,000.

For the second year, Mr. Ford committed a portion of his bonus of restricted stock equivalents to the William Clay Ford, Jr. Scholarship Program, providing tuition assistance for children of Ford employees, and a remaining portion to Detroit charities.

Jim Padilla, president and chief operating officer, earned $966,667 in salary and $2,034,910 in bonus, which consisted of $1.18 million in cash and a grant of 69,000 shares of unrestricted common stock worth $854,910, as well as $314,131 in other compensation. He also was awarded options to purchase 100,000 shares of common stock in long-term compensation. In addition, for his performance in 2004, Mr. Padilla was awarded a bonus in the form of 246,696 shares of restricted common stock and received 50,000 restricted stock equivalents as a long-term incentive grant, and for his promotion to Chief Operating Officer. Combined, these shares and stock equivalents have a fair market value of approximately $3,761,000 at the time of grant. Mr. Padilla also received a Long Term Incentive Plan award of $173,460 which was paid in unrestricted common stock for the 2002-2004 performance period. He also exercised option grants covering 82,499 shares with a realized value of $686,000, at the same time retaining 29,849 of those shares.

Greg Smith, executive vice president and president, The Americas, earned $756,667 in salary and $1,120,970 in bonus, which consisted of a cash award of $836,000 and a grant of 23,000 shares of unrestricted common stock worth $284,970, in addition to other compensation totaling $48,227. Mr. Smith also was awarded options to purchase 50,000 shares of common stock as a form of long-term compensation. He also received a Long Term Incentive Plan award of $105,315 which was paid in unrestricted common stock for the 2002-2004 performance period.

Nicholas Scheele, former president and chief operating officer, earned $1,000,000 in salary and $1,514,530 in bonus, which consisted of a cash award of $1,180,000 and a grant of 27,000 shares of unrestricted common stock worth $334,530, in addition to other compensation totaling $397,985. He also was awarded options to purchase 81,168 shares of common stock in long-term compensation. He also received a Long Term Incentive Plan award of $929,250 which was paid in unrestricted common stock for the 2002-2004 performance period.

Allan Gilmour, former vice chairman, earned $1,050,000 in salary and $1,517,880 in bonus, which consisted of a cash award of $997,500 and a grant of 42,000 shares of unrestricted common stock worth $520,380. Long-term compensation for his services as vice chairman was 300,000 shares of restricted common stock in 2004. In addition, he received $1,038,731 from his retirement plans associated with his earlier years of service with Ford Motor Company.

(“Other compensation” refers to certain tax reimbursements and various perquisites such as required use of the company aircraft. Other details are noted on page 33 of the proxy statement.)

The Compensation Committee of Ford’s Board of Directors, which is composed of independent directors, determines compensation of the executives listed in the proxy statement.

WebProNews | Breaking eBusiness News
Your source for investigative ebusiness reporting and breaking news.

This alert note was posted by Typepad at the weekend.

Today, though, for a period of about two hours this afternoon, I could neither log in to TypePad nor see my blog. Alarmingly, I was getting error messages in the browser saying “(111) Connection refused. The remote host or network may be down. Please try the request again.”

I couldn’t access any other TypePad-hosted blog either during this time.

Hopefully, TypePad will soon resolve whatever the problems are. Sorry if you’ve been inconvenienced today.

Edit: Posting this entry took nearly 10 minutes, with “Waiting for www.typepad.com…”displayed in the browser status bar the whole time.

What’s especially a concern is when you get an error message like this right in the middle of the publishing process:

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /t/app/weblog/post.
Reason: Error reading from remote server

This happened twice. Luckily the post was successfully published. Eventually.

Neville Hobson is the author of the popular NevilleHobson.com blog which focuses on business communication and technology.

Neville is currentlly the VP of New Marketing at Crayon. Visit Neville Hobson’s blog: NevilleHobson.com.

In this article we’ll examine the two parts of a Web Service: how to create it and how to consume it. Specifically, we’ll be creating a Web Service that exposes the FAQs from ASPFAQs.com.

Creating the Web Service

When creating a Web Service you must ask yourself, “What service am I trying to provide my users?” The goal of this article is to create a Web Service that will allow other Web sites to provide a listing of the FAQs from ASPFAQs.com on their site. Ideally, I want to restrict other sites to only being able to view the listing of FAQ categories and the FAQs by category. If they wish to view an “Answer” to a FAQ, I want the user to have to visit www.aspfaqs.com. Formally, my Web Service should provide other Web sites the ability to:

1. View a listing of all of the FAQ categories

2. View a listing of all of the FAQs for a particular category

3. View the “Question” (but not the Answer) for a particular FAQ

Creating Web Services is quite simple. Start by creating a .asmx file (either through Visual Studio .NET or your favorite text editor (may I suggest Web Matrix, which has a template for creating Web Services)). The Web Service is created as an ordinary class; the methods that have the <WebMethod()> macro before them indicate the method is accessible via the Web Service.

For the ASPFAQs.com Web Service, we will create three Web Service-accessible methods: GetCategories, GetFAQsInCategory, and GetFAQ, which perform the tasks (1), (2), and (3) outlined above, respectively. A private helper function, GetDataSet, is also included, which essentially populates a DataSet based on a passed in SQL query. The code for our Web Service class can be seen below:

<%@ WebService Language="VB" Class="ASPFAQs" %>
Imports System.Web.Services
Imports System.Data
Imports System.Data.SqlClient
Imports System.Configuration

&nbsp <WebMethod()> Public Function GetFAQ(FAQID as Integer) as DataSet
&nbsp&nbsp Return GetDataSet(SQL Query for Retrieving the FAQ FAQID)
&nbsp End Function
End Class

Some things to note: the three Web Service-accessible methods are predicated with <WebMethod()>; at the top of the .asmx file is a @WebService directive that specifies the language and class in the file; the Web Service is named ASPFAQs, as shown by the class name. Once you have created this .asmx file and stored it on a Web-accessible directory, you can view the methods by visiting the page directly through your Web browser. For example, I named my Web Service file ASPFAQs.asmx and saved it in the /ws directory; so, by visiting http://aspnet.4guysfromrolla.com/ws/ASPFAQs.asmx, you can see a listing of the Web Method’s public methods. Furthermore, you can “try out” the Web Methods by providing input parameters and viewing the returned results.

If you’ve read the Protecting Yourself from SQL Injection Attacks article you may be concerned that in using Web Services that accept parameters that are used directly in a SQL statement you are opening yourself up to a SQL Injection attack. (The GetFAQsInCategory and GetFAQ are two such methods that may concern the alert reader.) However, SQL Injection attack is not a problem here because the Web Service code automatically ensures that the input parameter is of the correct type, which is Integer here. Hence, if a malicious user attempts to pass to the Web Service an input parameter of, say, 0 ‘malicious SQL statement, an error message like Cannot convert 0 ‘malicious SQL to System.Int32. Parameter name: type –> Input string was not in a correct format will be returned. If, however, the input string is of type String, you should be sure to sanitize the input string by replacing all single apostrophes with two successive single apostrophes.

As the creator of the Web Service, our job is done – we’ve created the Web Service and other Web sites can now use it through their Web site. You may be wondering, though, how a Web Service can be “consumed” by another Web site.

Consuming a Web Service

For a Web site to consume a Web Service, a rather complicated and terse communication must occur between the client Web site (henceforth referred to as the “consumer”) and the Web site that is providing the Web server (henceforth the “producer”). Essentially, the consumer must decide what producer’s method it wishes to call. If there are input parameters, these parameters must be converted into XML to be passed along. An HTTP request is then made from the consumer to the producer, specifying the method it wishes to call and passing along the parameters in either a SOAP request, through the QueryString, or in the POST headers.

The producer receives the incoming request, unpackages the input parameters, and calls the appropriate method of the specified class. This method, when complete, returns some value, which is packaged up and sent back to the consumer in an HTTP response. The consumer receives this response, unpackages the return value, completing the Web Service call.

Clearly we’d like to not have to worry about the HTTP message passing semantics at all when using Web Services. In order to remove this as a concern, we use what is called a Proxy class. Proxy classes serve as an intermediate step between the program (or Web page) on the consumer and the actual Web service on the producer. For each method in the producer’s Web Service, there is a method in the Proxy class. It is the responsibility of the Proxy class to do all of the complicated message-passing tasks; essentially this complexity is hidden in the class, our Web page can simply call the methods of this class and not concern itself with the underlying semantics involved in calling a Web Service.

What in the World did he just Say?

By this point you’re likely thoroughly confused, and that’s understandable, this can be a confusing topic. The fundamental thing to understand is that the HTTP communications that must occur between a consumer and producer when calling a Web Service can be complicated and require much code. We’d prefer to have our Web pages that utilize Web Services be able to invoke the Web Service just as if it were a local component. In order to accomplish this, a Proxy class is used, whose public interface mirrors that of the Web Service. If you are still confused, consider viewing this PowerPoint presentation, which illustrates how to consume a Web Service. (Note that it shows how to create the Proxy class from the command-line; in this article we’ll be using Visual Studio .NET.)

Creating the Proxy Class in Visual Studio .NET

Creating a Proxy class for a Web Service is a breeze in Visual Studio .NET. In your ASP.NET Web Project, simply right click on the References icon and choose to “Add a Web Reference.” A dialog box will appear asking you for a URL – simply enter the URL of the Web Service, such as: http://aspnet.4guysfromrolla.com/ws/ASPFAQs.asmx. You will then see the description of the Web Service (just as if you had visited the URL directly through your Web browser). To complete this task, click the “Add Reference” button, which will automatically create the Proxy class for you and compile it.

When added to your project the Proxy class’s namespace will likely be the URL of your site, for example: com.4guysfromrolla.aspnet. (You can rename this if you so choose.) To call the Web Service from a Web page you use the Proxy class like you would any other local component. Imagine that we wanted to display a list of the FAQs from the ASP.NET category (which has category ID 22). We could do this by making a call to the GetFAQsInCategory method of the Web Service, passing in the parameter 22, and binding the resulting DataSet to a DataGrid, like so:

'HTML content in .aspx page...
<asp:datagrid id="dgCategoryFAQs" runat="server" />

&nbsp 'Bind the results of GetFAQsInCategory to dgCategoryFAQs
&nbsp dgCategoryFAQs.DataSource = consumeWebService.GetFAQsInCategory(22)
&nbsp dgCategoryFAQs.DataBind()
End Sub

From simply examining the code you could not determine that the call to the com._4guysfromrolla.aspnet.ASPFAQs Proxy class is, in actuality, a remote Web service call. When the Proxy class’s GetFAQsInCategory method is called, the complex communications discussed previously occur (the remote HTTP request/response dialogue).

Creating a Proxy Class without Visual Studio .NET

Creating a Proxy class through Visual Studio .NET is very easy; however, if you don’t have Visual Studio .NET, you can still create Proxy classes, but you must do so through the command-line. For more information on this technique be sure to read the PowerPoint presentation: Calling a Web Service from an ASP.NET Web Page.

Conclusion

In this article we examined how to create a Web Service and then how to consume it from an ASP.NET Web page using Visual Studio .NET. Microsoft has really simplified the process of producing and consuming Web Services with .NET. Creating a Web Service is as simple as creating a .asmx file and writing the code for the Web Service methods – save for the <WebMethod()> macros, the code appears nearly identical to the code one would write for a local component. Consuming a Web Service is painfully simple too, thanks to the use of Proxy classes. On top of that, the creation of Proxy classes is utterly simple through tools such as Visual Studio .NET.

*Originally published at 4 Guys From Rolla.com

Scott Mitchell, author of five ASP/ASP.NET books and founder of 4GuysFromRolla.com, has been working with Microsoft Web technologies for the past five years. An active member in the ASP and ASP.NET community, Scott is passionate about ASP and ASP.NET and enjoys helping others learn more about these exciting technologies. For more on the DataGrid, DataList, and Repeater controls, check out Scott’s book ASP.NET Data Web Controls Kick Start (ISBN: 0672325012). Read his blog at : http://scottonwriting.net

Technologies that predate mainstream Web services offer a dual nature in the way they fit into frameworks. The likes of ONC RPC, CORBA, and XML-RPC can be comprised either through the language-specific stubs that drive their common usage or through their wire formats. Web services consist of more than just RPC style, of course, but this style does dominate its mainstream use. What this means in practice is that developers create stubs for remote objects by writing compatible interfaces by hand, processing WSDL files, or even dynamic methods and introspection. But the services invocation then comes as a simple method call.

As these method calls get marshaled to wire formats and stream across the network, developers and administrators often want to keep track of things by maintaining detailed transaction logs in order to debug service behavior, profile performance, test security controls, and even model traffic shape for service-level improvement. A variety of vendors have lined up to provide tools to help with such monitoring, almost all of which focus on actual wire transactions. You can even get a box from some vendors that you pop into the rack in your data center, and plug into the network to gain such monitoring capabilities

Wire monitoring tools are generally expensive and require a lot of set-up and care. Considering that the idea behind Web services is that interchange can come from a diversity of end-points in a diversity of languages and platforms, wire monitoring is probably the most comprehensive approach in an enterprise environment. Then again, in reality most Web services in deployment are intra-departmental and even point-to-point. When Web services are used as an applications integration tool, such comprehensive monitoring is rarely needed. Even when such comprehensiveness is justified, it often makes sense to defer deployment of full-blown monitoring systems until production testing, which means that developers in earlier phases still need a means of keeping track of Web services for debugging and planning purposes.

It is also useful to have the ability to support Web services monitoring through the operation of the programming language stubs at the end points. The most general way of approaching this is by using techniques of function composition according to available language features. Most programmers think of such techniques as building wrappers and proxies.

Compose your methods

In functional and dynamic languages, function composition is usually straightforward at its root and flexible enough to come in numerous implementations. To demonstrate the basic technique, Listing 1 shows Python code that uses dynamic features to log all invocations of a remote method to standard error on the console.

Listing 1. Demonstration of function composition in Python for mixing logging capabilities into SOAP

import sys #Use standard system object of the interpreter
import SOAPpy #Use the third-party SOAP/WSDL toolkit SOAPpy

#From here on all invocations of methods on the Web service
#Automatically go through the logging code first
zipcode = '80027'
temp = wrapped_service.getTemp(zipcode)
print 'Temperature in US postal code ', zipcode, 'is', temp, 'F'

The definition of the class logging_proxy need only occur once. You can then wrap just about any class with it to meld in the logging capability. If you’re not familiar with Python, this function might be a bit hard to follow. The heart of the technique is the definition of log_wrapper, which forms what is called a closure. For Java programmers this is reminiscent of inner classes. The closure captures the information about the actual Web service method stub to be invoked (the function object called obj) as well as the stream for the log output. The caller gets this closure when it invokes a SOAP method by name, which triggers the special method __getattr__. In usual cases of method invocation the return result is a function object, which is then executed. In this case the returned function object is a closure which encapsulates some logging code and the data needed to call the original function. The overall effect is a composition of the log_wrapper code and the actual remote method invocation. The rest of the code in the module puts the technique to use. Only one additional line is required besides the usual SOAP client code:

service = logging_proxy(service, sys.stderr)

This one-time set-up is required for each remote service. As you can see, the output stream is parameterized: You can send some logs to a file and others to a network socket. You can parameterize other details easily enough. Overall, this technique provides a huge amount of flexibility. The following snippet shows the output from Listing 1:

$ python listing1.py
Invoking remote method getTemp
&nbsp&nbsp&nbsp positional params: ('80027',)
&nbsp&nbsp&nbsp named params: {}
Method getTemp completed
&nbsp&nbsp&nbsp Return value: 21.0
Temperature in US postal code 80027 is 21.0 F

The last line represents the normal processing of the method result. The five previous lines are output from the logging code.

A proxy on your network

Another approach to monitoring is to listen at the network level. Simply set up a proxy server of your own that performs some monitoring action while forwarding traffic to and from each remote service end-point. The proxy server listens on the same protocol as the remote server, but when it gets a request it simply performs the necessary action, such as logging the request. It then forwards the request to the remote service, and passes any response back to the original client. Listing 2 is a program that operates as such a proxy for SOAP over HTTP. It’s also in Python, but the nature of this proxying approach is such that this code can be used with any Web service regardless of the language used to implement either SOAP end point.

Listing 2. Script that logs then forwards SOAP/HTTP messages

import sys
import BaseHTTPServer
import httplib

LISTENING_PORT= 8888
#Set up to run on local machine
SERVER_ADDRESS = ('127.0.0.1', LISTENING_PORT)
httpd = BaseHTTPServer.HTTPServer(SERVER_ADDRESS, ProxyHandler)
print "Listening on port", LISTENING_PORT
#Go into a the main event loop
httpd.serve_forever()

The method do_POST on ProxyHandler is executed once the server receives SOAP by way of an HTTP POST invocation. It logs the HTTP headers and payload (that is, the SOAP message) and then makes an equivalent call to the actual remote end point. The HTTP response from the remote end point is forwarded back to the original client. This proxy code is very flexible because, if used correctly, it can determine the actual destination from the HTTP headers. In the code, this is read into the dest variable. This means that you can use this one SOAP/HTTP proxy to handle any number of requests for all variety of actual destination end points. The original clients see the same network traffic as if they were communicating to the remote server directly. Listing 3 is an example of client code that uses the SOAP/HTTP proxy.

Listing 3. SOAP client that proxies its messages for logging

import sys&nbsp&nbsp&nbsp #Use standard system object of the interpreter
import SOAPpy&nbsp&nbsp&nbsp #Use the third-party SOAP/WSDL toolkit SOAPpy

zipcode = '80027'
temp = service.getTemp(zipcode)
print 'Temperature in US postal code ', zipcode, 'is', temp, 'F'

This is pretty much boilerplate remote procedure calling code except for the line:

service.soapproxy.http_proxy = 'localhost:8888'

Most SOAP libraries give you a mechanism for directing a SOAP request through a proxy. This line sets an HTTP proxy for the SOAP client, pointing it to port 8888 on the local machine. Because setting the HTTP Host header is a standard step in using an HTTP proxy, very little additional work is needed to get the proxy server to forward the traffic properly.

The main limitation with this HTTP proxy trick is that you have to add more customization to handle usage patterns that are more complex than the common request/response interaction. Luckily, such customization isn’t terribly difficult.

Wrap up

I have just scratched the surface of function composition and the capabilities of network service proxying. These themes have many variations and most languages support similar capabilities. If you’re using a functional language (such as Python), you can follow up on these compositional tricks by experimenting with currying and other such techniques. If you’re using a static object-oriented language such as Java, look into aspect-oriented programming (AOP). Programmers have lots of options for adding infrastructural capabilities to Web services without having to buy expensive wire monitoring tools.

Resources

Find out how you can become an IBM Certified Developer in XML and related technologies.

Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is also a lead developer of the Versa RDF query language. He is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can contact Mr. Ogbuji at uche.ogbuji@fourthought.com.

Speculate on the proxy results in WebProWorld.

Peek-a-boo! Site Match Links Say Hi

Check out the Yahoo proxy search here.

Ronniethedodger pointed to what he thought were Site Match results:
http://rds.yahoo.com/S=2766679/K=money+business/v=2/TID
=F251_44/SID=e/l=WS1/R=6/H=0/*
-http://www.everythingaboutvitamins.com/.

These links are what Daniel Brandt calls, “plain “click counter” redirects that appear on every URL.”

Tim responded that this was not in fact a Site Match link, and that Site Match links look like this:
rdrw1.yahoo.com/click?u=http://www.ibiblio.org/tkan/xmcd&
y=022F06033A99E6E8&i=482&c=9106&
q=02%5ESSHPM%5BL7%7C%7B%3Fos~fzm6&e=utf-8&r=25&
d=wow-en-us&n=8R545H097DP408T1&s=21&t=&m=4072437D
&x=01D37651EA37F317.
(For the unmangled link visit Yahoo’s post.)

If you’d like to see Yahoo’s results unveiled check out Daniel Brandt’s proxy search over at Search showdown: Yahoo v. Google. Brandt’s proxy strips out the first redirect that appears on a standard Yahoo search, and it’s in the secondary redirects that we see the “rdrw1.”

The proxy gets results from two different data centers, so sometimes the beginning “rdrw1″ changes to “rdre1.”

Brandt’s been recording data and has identified several parameters in the url that are likely to have some bearing regarding how these links are added to the results.

The identified (though yet undefined) parameters are:

MI=ic
MI=ss
MI=free
MI=other
MI=sitematch

Brandt’s proxy search is an excellent way to see which of your competitors have possibly paid to get urls in Yahoo’s results.

WebProNews and Google-Watch appear with the MI=other parameter and neither of us have paid for inclusion, which suggests a relationship between MI=other and RSS feeds.

Brandt added that, “[Danny] Sullivan’s site was this way when we talked two weeks ago, but now his XML ‘My Yahoo’ link is gone in the main search.yahoo.com listings, and he has a normal link on my proxy. So that reinforces the theory that the XML and MI=other are related.”

As Yahoo’s set to drop the Inktomi pfi links on April 15th, what we’re seeing now may change dramatically. Says Brandt, “I am interested in how the links will change on April 15 — how many of what Tim calls a Site Match link, and what I merely refer to an ‘almost all of them are paid’ link, will get dropped by Yahoo.”

Check out the Yahoo proxy search.

Garrett French is the editor of iEntry’s eBusiness channel. You can talk to him directly at WebProWorld, the eBusiness Community Forum.