Gnutella Doesn't Need the X-Alt HTTP Header

Gnutella is a popular P2P file sharing protocol. One of its strengths is that it uses HTTP as a transport protocol; it uses HTTP for the actual file transfers.

To aid in distributing the burden of and to increase the intelligence of file transfers, Gnutella introduced the X-Alt HTTP header. The pupose of this HTTP header is so that a Gnutella servant can let other Gnutella servants know about alternate locations of the same file or resource.

However, there is no need for Gnutella to introduce a new HTTP header just for specifying alternate locations of the same file or resource. HTTP already has a mechanism for specifying alternates. HTTP already has the Link header which could be used for this.

HTML Link Element

The HTTP Link header is meant to mimic the HTML <link> element. (Understanding the HTML <link> element will aid in understanding the HTTP Link header.)

HTML has the ability to describe semantics between resources. On such facility for doing this the HTML <link> element.

With the HTML <link> element one can specify relations between the page the HTML <link> is contained within and any other file or resource (which can be referred to with a URI) and vice versa.

Here is an example of the HTML <link> element being used to specify the home page for the page the HTML <link> element is contained within.

  <link rel="home" type="text/html" href="http://changelog.ca/" />
                

And here's an example of the HTML <link> element being used to specify an alternate version to the page the HTML <link> element is contained within.

  <link rel="alternate" type="application/atom+xml" href="http://changelog.ca/feed" />
                

(Some may know this particular usage of the HTML <link> element as RSS, Atom, or webfeed auto-discovery.)

And here's an example of the HTML <link> element being used to specify 2 different versions of the home page.

  <link rel="home" type="text/html" href="http://changelog.ca/" />
  <link rel="home" type="application/rss+xml" href="http://changelog.ca/feed" />
                

(For more information on the HTML <link> element see Section 12.3 of the HTML 4.01 specification. And for more information on the different relations see Section 6.12 of the HTML 4.01 specification.)

HTTP Link Header

Since version 1.1, the HTTP protocol has had a semantic equivalent to the HTML <link> element. Namely the HTTP Link header. (See section 19.6.2.4. of RFC 2068 for more info.)

Here is an example HTTP response with the HTTP Link header.

  HTTP/1.1 200 OK
  Date: Tue, 13 Jun 2006 21:17:19 GMT
  Server: Apache/2.0.46
  X-Powered-By: PHP/5.0.3
  Link: <http://changelog.ca/feed> ; rel="alternate"; type="application/atom+xml"
  Connection: close
  Content-Type: text/html
                

The HTTP Link header in that HTTP response is semantically equivalent the following.

  <link rel="alternate" type="application/atom+xml" href="http://changelog.ca/feed" />
                

HTTP Link Header Use Cases

Although, in many cases, using both the HTTP Link header and the HTML <link> element is redundant; there are situations where the HTTP Link invaluable.

For example, the HTTP Link header is invaluable when the file or resource located at the requested URL is NOT an HTML file (and has no native way of specifying typed links).

Here's an example illustating that use case.

  HTTP/1.1 200 OK
  Date: Tue, 13 Jun 2006 21:17:19 GMT
  Server: Apache/2.0.46
  X-Powered-By: PHP/5.0.3
  Link: <http://example.com/show/123.mpeg> ; rel="alternate"; type="video/mpeg"
  Link: <http://example.com/show/123.ogm> ; rel="alternate"; type="video/ogg"
  Connection: close
  Content-Type: video/x-msvideo
                

Although you can't tell from the example, the request made (that generated this response) was for an AVI video file. But the video file is also available in MPEG and OGG formats, which is communicated through the use of the HTTP Link header.

Another use case is that, the HTTP Link header is invaluable when the requested file or resource can NOT be modified but it is desired to add additional typed links. Perhaps because of locals laws. Perhaps because the server (which is proving access to the resource) is not sophisticated enough to properly inject HTML <link> elements.

In addition to those, the HTTP Link header is invaluable when an HTTP HEAD request is made for a file or resource and thus no body would be returned with the HTTP response (and thus the client would NOT receive any typed links specified with HTML <link> elements).

(There are likely other useful use cases for the HTTP Link header.)

rel-alternate

One specific relation (predefined in the HTML specification) that is relevant to Gnutella is the alternate relation.

Plain and simple, the alternate relation let's you specify alternates.

Here's some examples.

  <link rel="alternate" type="application/atom+xml" href="http://changelog.ca/feed" />  
                

  <link rel="alternate" type="application/atom+xml" href="http://example.com/feed.atom" />  
  <link rel="alternate" type="application/rss+xml"  href="http://example.com/feed.rss"  />  
                

  <link rel="alternate" media="tv"    type="application/smil+xml" href="http://example.com/index.smil" />  
  <link rel="alternate" media="radio" type="audio/mpeg"           href="http://example.com/index.mp3" />  
                

Gnutella and the HTTP Link Header

Gnutella uses a X-Alt to specify alternate locations of the same file or resource. This is not needed. This same semantics could be expressed through the use of the HTTP Link header.

For example, the follow X-Alt header...

  X-Alt: urn:sha1:4727ac07221adba9875a894738eeff9cc7fdd214; 192.0.2.17:6347, 192.0.2.44
                

... could be replaced with...

  Link: <urn:sha1:4727ac07221adba9875a894738eeff9cc7fdd214> ; rel="alternate"
  Link: <http://192.0.2.17:6347/uri-res/N2R?urn:sha1:4727ac07221adba9875a894738eeff9cc7fdd214> ; rel="alternate"
  Link: <http://192.0.2.44:6346/uri-res/N2R?urn:sha1:4727ac07221adba9875a894738eeff9cc7fdd214> ; rel="alternate"
                

(Note that we made use of the fact that the default TCP port file transfers are made for Gnutella, over HTTP, is port 6346. And that requests for files are made for Gnutella, over HTTP, are at "/uri-res/N2R?urn_goes_here".)

Conclusion

When HTTP already provides a mechanism to accomplish what you want to accomplish what you want to do, it is bad practice to create your own version of it.

(My guess is that the Gnutella developers did NOT do this on purpose though, but were just ignorant of the HTTP Link header.)

In the case of Gnutella and the HTTP X-Alt header, all that is done with Gnutella's HTTP X-Alt header can be done with the HTTP Link header.

Therefore it would be a good idea for Gnutella servants to support the HTTP Link header. It would be a good idea for Gnutella servants to be able to send and receive alternate locations with the HTTP Link header.

-- Charles Iliya Krempeaux, B.Sc.