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.
$this->clientError(_('No such user.'));
}
- // support redirecting to FOAF rdf/xml if the agent prefers it
- $page_prefs = 'application/rdf+xml,text/html,application/xhtml+xml,application/xml;q=0.3,text/xml;q=0.2';
+ // Support redirecting to FOAF rdf/xml if the agent prefers it...
+ // Internet Explorer doesn't specify "text/html" and does list "*/*"
+ // at least through version 8. We need to list text/html up front to
+ // ensure that only user-agents who specifically ask for RDF get it.
+ $page_prefs = 'text/html,application/xhtml+xml,application/rdf+xml,application/xml;q=0.3,text/xml;q=0.2';
$httpaccept = isset($_SERVER['HTTP_ACCEPT'])
? $_SERVER['HTTP_ACCEPT'] : null;
$type = common_negotiate_type(common_accept_to_prefs($httpaccept),