It seems the issue is in web.config, where it writes (at least it was like that in our web.config):

    <!-- Available values: identicon, monsterid, wavatar, full URL-encoded http address or virtual path of an image that should be served as a default image if there is no image for a particular address: http%3A%2F%2Fexample.com%2Fimages%2Fexample.jpg -->
</br>    <add key="GravatarType" value="/App_Themes/Common/img/avatar_blank.jpg" />

the comment there does have a URL-encoded example, but doesn't state it specifically that you should use such

also, I just realized I can use identicon there instead of a fixed image which is better I think if many users don't have a gravatar, by entering the value "identicon" at the above entry in web.config (documented at http://blog.gravatar.com/2008/04/22/identicons-monsterids-and-wavatars-oh-my/ too)

tried changing the entry to

<add key="GravatarType" value="~%2FApp_Themes%2FCommon%2Fimg%2Favatar_blank.jpg" />

but it doesn't work. Could it be the ~%2F ? Do I need to write / instead of ~%2F at start?

user Dorothy seems to now get the image
</br>http://www.gravatar.com/avatar.php?gravatar_id=94db843c14f311ce0ab4d26a8c037bb2&rating=G&size=80&d=%7e%252FApp_Themes%252FCommon%252Fimg%252Favatar_blank.jpg
</br>which is strange. Are you URL encoding that entry yourselves? In that case the comment in web.config needs to change to not have a URL encoded url, but a normal one

I ended up using "identicon" there (more "professional" than wavatar and monsterid in my opinion)

could the issue with the fallback URL not working be related to that other issue you fixed regarding the user gravatars and the cache?

I'm happier with the identicon, but would be nice to know the fallback image is an option that works

Hi Zoomicon,
the issue is not related to the previous fixed issue, it is actually a separate bug caused by the GravatarType being decoded in all cases.

It has been logged to the internal bug tracker and will be fixed in one of the next MonoX releases.

Regards,
Vedran