How To Use Mime-Types To Get Your Aggregator To Subscribe To An AtomFeed

There has been much talk today, and in the far past, of how to automatically handle syndication subscription. The conversation was first brought up and thoroughly discussed by Greg Reinacker. The issue has resurfaced on the [atom-syntax] mailing list. Now there are a small contingent of folks pushing for a new uri scheme called 'feed:' that would enable syndication subscription. Creating a new URI scheme is a bad idea, don't do it.

So what is the alternative to hooking onto a new URI scheme? Well, the correct way to this is to hook onto the mime-type. Mime-types are the fundamental way types of files are identified in HTTP, and SMTP and in other areas too but well just concentrate on HTTP for now. Atom feeds have the mime-type of 'application/atom+xml'.

How do we go about using mime-types to connect an Atom feed sitting on a web server to a client aggregator application? There are two sides to the equation, the client side, and the server side.

Server Side

In order for this to work the Atom feed must be server up with a mime-type of 'application/atom+xml'. There are two general cases to consider. Either the file is server up statically or it is generated on the fly by a CGI program. The CGI generated case is the easiest of the two. When producing the output from the CGI program just include the Content-type: header with the correct mime-type:

Content-type: application/atom+xml

The case for statically served files is only slightly more complicated, in this case you just need to let Apache know about the new mime-type. You do that by using the AddType directive, which maps a file extension to a mime-type. In the directory that you are storing the Atom feeds in add the following line to your .htaccess file:

AddType application/atom+xml .atom

Now any file stored with a .atom file extension will be served up with the mime-type of 'application/atom+xml'.

Client Side

The server side of the equation was easy, things get a little more complicated on the client side. To make things easier we'll assume you are running under Windows, people in the know of how to do these things under Mac and unix should feel free to speak up in the comments. Under Windows the mapping of mime-types to applications is handled through the registry. So let's walk through the process of setting up the registry to handle the Atom mime-type. To make the discussion concrete here is a little stub of a C program that is going to stand in for our aggregator:

  #include <stdio.h>
  #include <conio.h>
        
  int main(int argc, char * argv[]) {
     printf("Atom Handling Application.");
     printf("The Atom Feed is located at: %s\n", argv[1]);
     getch();
     return 1;
  }

When called this program just prints the command line argument it was passed and then waits for the user to press any key before the program completes. If you have Microsoft's C++ compiler installed you can build it with:

cl -GX handle.c

Or if you have the Borland compiler installed:

bcc32 handle.c

Either way you end up with an executable handle.exe. For the rest of this dicussion we'll assume that handle.exe is installed at the fixed location C:\AtomHandler\handle.exe. New values are then added to the Registry to map the mime-type application/atom+xml to our handler application. Just like under Apache mapping of mime-types is done using file extensions even if a file with that extension is never involved. I'll explain that in a minute. First we hook into the file extension .atom. The following three snippets are from exported sections of the registry. You would not actually hand edit or manually add these items to your registry, instead the application installation program needs to take care of this step.

[HKEY_CLASSES_ROOT\.atom]
        @="atom_file"

This binds the .atom extension to a name, a kind of indirection, of "atom_file". Now we need to add values to the registry to indicate what to do when encountering a file with this extension:

[HKEY_CLASSES_ROOT\atom_file]
@="Atom Syndication Program"

[HKEY_CLASSES_ROOT\atom_file\shell]

[HKEY_CLASSES_ROOT\atom_file\shell\open]

[HKEY_CLASSES_ROOT\atom_file\shell\open\command]
@="\"C:\\AtomHandler\\handle.exe\" %1"

Now this will run our handle application and pass the name of the file in as the first argument on the command line. The last step is to map the mime-type to the file extension. This is done with the following keys:

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/atom+xml]
        "Extension"=".atom"

Now you can see why the file extension is necessary, even if it is never used, that is, even if you never have a file with the extension ".atom" on your hard drive, you still need to register the extension so you have some thing to map through, from the mime-type to the extension and finally to the handling application. Now, at least under my testing with Mozilla and IE under Windows, both applications will now use this information to launch the correct application. Unfortunately IE comes up with rather ominous warning box the first time you click on an Atom feed:

Mozilla comes up with a similar, but less ominous dialog box the first time an Atom feed is encountered.

What happens is that the browsers download the file into a temporary location and then pass the name of that file to our handler application. At this point, if an aggregator was setup as the handler of the Atom feed it could parse the feed and ask the user if they wished to subscribe. Well...except that the aggregator can't subscribe to the feed because all it has is the feed, what it really needs is the URI of the feed. That is, the Atom feed the user just clicked on is stored on disk and the actual URI that the browser downloaded the file from is not avialable to the handling application. So to make this scheme work, the URI of the Atom feed needs to be included in the Atom feed itself. This is another place where the new 'link' tag syntax shines. If you look at the example feed I have provided it contains just such a tag, as a child of the feed element:

<link rel="self" 
        href="http://bitworking.org/projects/atom/examples/example-feed.atom"/>

Note that the link tag uses the attribute 'rel' with a value of 'self' to uniquely indicate that the 'href' attribute contains the URI of this Atom feed. Aggregator subscription to Atom feeds can be handled seemlessly without registering a new URI scheme. If the feed: URI scheme were followed it looks like it would actually require registering such a scheme with each browser installed on the computer.

Note: No matter what scheme ends up being used, the user must be prompted to confirm that they wish to subscribe to the feed. What the browser is doing is just retrieving a representation with GET and Agents do not incur obligations by retrieving a representation.

If you would like to test this out I have an example feed setup at http://bitworking.org/projects/atom/examples/example-feed.atom.

Further Reading

Using the Registry

Update

I have updated the text above and the example to reflect the final version of Atom 1.0.