libravatar-fans team mailing list archive
-
libravatar-fans team
-
Mailing list archive
-
Message #00012
Issues with the API specification
Hi,
I'm considering implementing my own libravatar server software and read
the api documentation on http://wiki.libravatar.org/api/
Several points are not clear to me, or are clear to me but should be
specified explicitely:
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.
2. Invalid input in the hash
The api allows md5 and sha256 hashes and acts differently if it sees a
md5 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.
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?
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?
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 :)
Since clients have to "force-scale" images on their side anyway, it
should be ok for servers to return images in approximate sizes.
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?
If 3 is answered with "approximate is ok", then this is a non-issue. If
exact sizes are required, then the server would need to scale up in my
eyes.
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?
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]+")
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?
7. Must avatar servers return the image directly, or are Location
header redirects allowed?
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)
Are libraries required to fall back to HTTPS libravatar.org when the
client requests HTTPS, but the federated server does not provide HTTPS
support?
--
Regards/Mit freundlichen Grüßen
Christian Weiske
-=≡ Geeking around in the name of science since 1982 ≡=-
Attachment:
signature.asc
Description: PGP signature
Follow ups