libravatar-fans team mailing list archive

[Christian Weiske <cweiske@xxxxxxxxxx>]

Hello Francois,


> > 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.
Yes, that's fine and future-compatible when avatar servers need to
support 4k icons for the 1024k displays :)


> > 2. Invalid input in the hash
> > 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?

Only relevant to people implementing their own server, not for users.


> > 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.

Seems I was wrong; the libravatar only returns a 404 when I shorten the
hash AND have an invalid default icon, e.g.

http://cdn.libravatar.org/avatar/40f8d096a3777232204cb3f796c577?d=foo


> 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.

The reason to send a 400 is that we clearly know that the hash is
invalid, and can never ever produce a valid result (except we begin to
support a hash function that produces hashes with 31 chars).
By sending a 400, we let the client know that he did something
wrong and should fix it.

In general we should do our best to educate the client developers by
letting them know that they did something wrong, instead of silently
ignoring all errors. This might lead to debugging headaches for the
client developer. 


> > 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."

No, I'd just state that the size parameter given to the server is just
a wish, and that the servers may - and many will - return the picture
at exact this size - but they do not *have to*.

We might want to specify that the images are always the exact size or
larger than requested. This would imply upscaling (point 4).


> > 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.
Then this should be stated in the spec.


> > 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.
Ok, then this should be in the spec, too.


> > 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?

If servers do not have to implement the default types supported by
libravatar.org, how do they know that the given default is a URL or an
unsupported default mode? Having a clear rule how such default modes
have to look makes the decision process very easy, without having to
url-parse the complete parameter.

Just imagine that I give a fake/custom default mode of
> ?d=http:/foo.bar/baz.png

Is that an URL? No, because the second / is missing. So the server may
not redirect to that URL but see it as "unsupported default mode" and
give out its default image or whatever he does when he does not have
the user image.

But determining that this is not a URL is hard, because for that the
supposed may-be-or-not URL has to be url-parsed, which is costlier than
just validating a simple regex. Having a clear rule how non-URL default
modes may look like would simplify that a lot:

If it does not match "^[a-z0-9]+$", redirect to that supposed URL. Done.

Which leads to another point: Do servers need to validate default URIs?
If yes, which protocols are supported? Is it ok to request a HTTP image
and have a https default URL? (I'd say yes)
If we have the default mode rule, we don't need to validate any default
URLs and just can send a redirect.


The use case for different modes ... maybe I've implemented a cool new
way to generate dynamic avatars, similar to monsterids - ponyid for
example. Do I want to wait for the libravatar spec to be updated? This
does not scale.


> > 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.
Fine.

> > 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?
No, but it should be stated that clients that e.g. want to cache the
images need to follow redirects.

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


> > 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.
Ok. The spec should state that.

> Do you think that's a problem?
What if SPDY gets more common? It's basically HTTPS over HTTP, so even
if you ask HTTP, you might get SPDY HTTPS.


> > 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.
Good reason. This should also be in the spec.



> 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 fetch photos from Libravatar
> 2- spec for developers writing their own Libravatar server

Thinking about that I've come to the conclusion that two docs would be
nice:
First the specification, which explains in clear, hard, dry words how
clients and servers need to behave.

The api docs would add examples, syntactic sugar and nice words to not
overwhelm people with too much detail.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

Attachment: signature.asc
Description: PGP signature