Bug 1655/bug 1905: fix for Internet Explorer receiving FOAF output when clicking...

Bug 1655/bug 1905: fix for Internet Explorer receiving FOAF output when clicking user links.

User links using the ID number (such as created for @-replies) have been failing on Internet Explorer, since IE doesn't bother to actually say it supports text/html...

We usually get something like this from IE, up through at least IE 8:
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*

The */* ended up matching application/rdf+xml instead of text/html, so only other browsers which are more explicit would actually get sent on to the user profile/notice stream; IE visitors were directed on to the FOAF download. :(

Swapping the order of items in the server-side of the negotiation list fixes this; clients actually asking for FOAF at a higher priority than HTML will still get it, but the wildcard */* now matches text/html which is usually what we want.

Content negotiation for the user links  was added August 2008 in commit 48fcfb8b0daeb272cb9d116af617daf15930d909.