libravatar-fans team mailing list archive

[Francois Marier <francois@xxxxxxxxxxx>]

On 2012-08-01 at 00:32:35, Christian Weiske wrote:
> Several points are not clear to me, or are clear to me but should be
> specified explicitely:

First of all, thanks for taking the time to highlight the areas where our
API/spec is lacking. It's really useful feedback!

I'd encourage others to chime in because these are fairly important points
that impact all developers interacting with Libravatar.

> 1. How is invalid input in the "size" parameter to be handled?
> For example, a client requests a size of "1s2", which is clearly not
> an integer. I think the server should return a HTTP 400 Bad request.

For very large requests (e.g. s=3000), both Gravatar and Libravatar cap the
size to the maximum size they suppport. I personally don't see a reason to
change this.

On the other hand, when using bogus size parameters like "1s2", the
behaviour is different:

- Gravatar: it extracts any leading digits and uses that as the size
  (e.g. "1s2" => 1x1, "4s2" => 4x4)
- Libravatar: picks the default size (80x80)

I think the 400 response makes sense here. We should signal to web/client
developers that their code is broken.

> 2. Invalid input in the hash
> The api allows md5 and sha256 hashes and acts differently if it sees a
> md5 hash.

Yes, only MD5 hashes will redirect to Gravatar.

> It should be stated that the "md5 hash detection" is purely a
> check if the hash is 32 chars, while sha256 hashes are 64 chars long.

Is that relevant to implementers or regular developers?

> Now what if the client sends a hash with 13 characters, or 31? Should
> the default icon be sent? Should a "400 Bad request" be sent? (the
> correct answer in my eyes) Should a 404 be sent, as the libravatar
> server does currently?

Currently (as far as I can tell) both Libravatar and Gravatar return the
default image for hashes of incorrect sizes. Can you tell me the URL of a
broken hash that returned a 404 on Libravatar? I haven't been able to find
one.

Is there a reason to deviate from the Gravatar behaviour here and send a
400? I agree it feels more correct, but I feel like compatibility with
Gravatar might be more important in this case.

> 3. Is the server expected to return the exact size that is requested?
> Or is it ok to return the 32x32 icon when the client requests the 31x31
> one?

Currently, the assumption is that clients get the exact size they requested.

> While one might be inclined to say "the exact size", you have to
> consider that it's a protocol with federation support. This means
> servers may return faulty data, including images with strange sizes.
> This single point simply requires clients to always add width and
> height attributes to their HTML image tags, because otherwise their
> page layout may totally break when a faulty/bad server returns
> 2048x2048 images, or an image of size 1x123456789 :)

That's an excellent point.

> Since clients have to "force-scale" images on their side anyway, it
> should be ok for servers to return images in approximate sizes.

How would you phrase the relevant bit in the spec? "If an image of the exact
size isn't found, the nearest image of a size greater than that will be
returned. If such a larger image doesn't exist, a smaller image may be
returned."

(That wording sounds a bit clumsy to me...)

> 4. What happens with images that are too small?
> Imagine the user uploads a 32x32 image and a client requests the
> 512x512 variant. Shall the image be scaled up?

That's how it's done in both Gravatar and Libravatar.

> 5. Which default URLs should be supported?
> Libravatar.org supports URLs, mm, identicon, monsterid, wavatar and
> retro. Does every server have to support those? Is it ok to not support
> them and return a default icon?

I would say that these are specific to libravatar.org and I don't think we
should impose anything on third-party servers.

> Is it allowed to support more of them, e.g. "myfakeidenticon"? If yes,
> how should servers that do not implement them behave? What are the
> rules for the names of the default modes? (I'd say "[a-z0-9]+")

I'm not sure we should allow new ones though. Do you think that's important?
What's the use case for it?

> 6. Gravatar
> Does my server have to redirect to gravatar.com if it does not have an
> avatar icon for a given hash? May it redirect to libravatar.org?

No, I think that if you own your domain, you get to control your redirection
policy. You can choose to redirect to these services or not. It's up to
you.

When I initially set up the catalyst.net.nz Libravatar server, it would just
show a Catalyst logo when an email wasn't found. No redirections anywhere.

> 7. Must avatar servers return the image directly, or are Location
> header redirects allowed?

I don't really see a problem with redirections. Should we restrict the ones
that can be used though?

Obviously we need to support 302s (and its HTTP/1.1 cousin), but does 301
make sense?

> 8. HTTPS support: Is it ok to provide HTTPS avatars only?
> Or do I have to provide a _avatars._tcp.example.com entry in my DNS?
> If I have to provide it, may I simply state that it's on port 443?
> (probably not, since the type "_avatars._tcp" implies the HTTP protocol)

The current assumption is that if a site requests HTTP avatars, it gets HTTP
avatars, not HTTPS ones. Therefore if you only expose _avatarssec._tcp, a
client library should fall back to libravatar.org for HTTP requests.

Do you think that's a problem?

> Are libraries required to fall back to HTTPS libravatar.org when the
> client requests HTTPS, but the federated server does not provide HTTPS
> support?

Yes. Falling back to HTTP would trigger mixed content
warnings/errors in browsers.


Another point that was raised on IRC and which I'd like to get feedback on
is whether or not we need two documents:

1- API docs for sites wanting to add photos from Libravatar
2- spec for developers writing their own Libravatar server

Cheers,
Francois

-- 
Francois Marier           identi.ca/fmarier
http://fmarier.org      twitter.com/fmarier