User Comments

All feeds are serviced via the Coral peer-to-peer content distribution network.

No they are not! According the instructions on the coral website urls should have a suffix of “.nyud.net:8090” in order to pass through their network. My subscription to your RSS doesn’t include that suffix.

Furthermore, looking at your “Syndication” page, I notice that the urls there don’t have the coral suffix either.

However, the orange “XML” button does request the corresponding feed through coral.

This means that ONLY new users who use the “XML” button are going to be served via coral.

I think you need to do a little more work on this. Sorry! :-(

No they are not!

Oh yes they are! :-)

Aaron, the requests are redirected with the magic of mod_rewrite.

I had to do it this way otherwise your assertions would be correct. Without mod_rewrite, I would have had to update all RSS links within the website AND I would have had to encourage existing subscribers to subscribe to a new URI. The first wouldn’t be a problem, but the second would cause an unnecessary annoyance - especially since these changes are only experimental at present and might not remain in force.

You can prove that rewriting is handling the RSS links by looking at the source of this page (for example). Look at the link for the orange “XML” button and you’ll see that it is a relative link to “/folders/blog/syndicate.rss”. However, when you click the button, you end up at a different URI (http://urbanmainframe.com.nyud.net:8090/folders/blog/syndicate.xml).

Clever eh? :-)

{writing with a sheepish grin}

That’ll teach me. Sorry Jonathan. I should have investigated further before I posted. I should’ve known you’d have addressed this. :-)

Cool! I’d like to compress mine and work the headers a little better. Gettin a lot o’ hits, and the ‘bee in yer bonnet’ is a valid one…

Bob Wyman is advocating another bandwidth-conserving RSS delivery mechanism using RFC3229 (Delta Encoding in HTTP) to serve only the changes between the current request and the previous one.

His proposal, “Using RFC3229 with Feeds”, looks pretty sound to me…

UPDATE:

A log analysis and a little bit of math shows that, with Coral enabled on my RSS feeds, I am currently serving only 4.27 RSS requests per hour.

That’s way, way better than I expected. Go Coral, go!

I can suggest a reason you might be serving less RSS feeds. You might have lost some

You lost me until I realised I hadn’t heard from your feed in a while. Even worse, this post was the first one I missed, hence I had no indication in my feed that something about the feed might have changed (interesting usability issue for next time)

So, the redirect isn’t working for me and your new URI doesn’t work either - can’t find urbanmainframe.com.nyud.net… I’ve done some fiddling both with the URIs and with my reader (RSS Bandit) and I can’t resubscribe

Sorry it took so long to bring this to your attention, but I was on holidays and at Web Essentials and when I got back my computer was kaput (I’m currently on a temporary hack machine). Feel free to email me if you want more info or screen captures etc

That’s strange Lachlan. I’m subscribed to the weblog feed myself (I wanted to make sure the caching wasn’t interfering) and I’ve had no problems. Nor have any issues been reported by others.

I know the feeds are available and that the redirects are working because services such as blo.gs are detecting my updates successfully. Also, I can see the feeds if I request them by URL!

I will look into this though. Thank you for bringing it to my attention.

I wonder if RSS Bandit is missing the feeds because they are gzip-encoded?

That the problem lies with RSS Bandit is a distinct possibility, especially given that you have no problems with your feed. I have no idea if it supports gzip encoding or not. I’ll have to investigate, but I really don’t want to change as it is the best reader I’ve found so far

Perhaps (1) a firewall you are behind is blocking port 8090, or (2) you are behind a buggy DNS resolver:

http://coral.scs.cs.nyu.edu/wiki/wiki.php/Main/FAQ#SERVFAIL

Some DNS servers do not support DNAME records (RFC 2672). Coral uses such records to help client reuse nearby Coral DNS servers once such servers are discovered. While old resolvers should fail gracefully given additional information provided by Coral DNS servers — that is, they should use the other record types returned by Coral, and just ignore the DNAME records — some (including Windows 2000 DNS servers) unfortunately do not and just incorrectly reject the entire response. We are currently looking into some alternative mechanism or work-around that enables similar functionality.

While this obviously isn’t an ideal solution, users that cannot access DNAME records can try to append http.l2.l1.l0.nyucd.net:8090 (note the “C” in nyuCd) to the end of hostnames, instead of the traditional .nyud.net:8090, to be able to use Coral today.

That’s great feedback Reader. It’s always useful to have “insider” information. Thank you.

I am no longer gzip-encoding the RSS feeds as the compressed feeds seem to be unreadable to some readers.

There’s a new kid on the block: RSScache