libravatar-fans team mailing list archive

[Jonathan Harker <jon@xxxxxxxxxxx>]

On 2/08/2012 9:13 a.m., Christian Weiske wrote:
> > > 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 :)

I wonder if we should cap file size as well, perhaps as a multiplier of
maximum size, in case some folks start uploading massive animated
PNGs, c.f.

https://en.wikipedia.org/wiki/APNG
https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png

Or perhaps we should have that as a server option - allow/deny
animated avatars, accept/reject PNG files with acTL chunks. Might
be a moot point as it's currently only supported in Gecko and
Opera.

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

Are there any weird safety or security issues we should worry about
around also restricting hash characters to [a-z0-9] as well, and return
400 if it looks fishy? For some reason the words buffer underrun
spring to mind.

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

I agree about compatibility with Gravatar, but to what extent does
returning a 400 instead of a 404 break that? If the receiving client takes
400 as success because it's only ever expecting 200 or 404, I guess it
may have bigger problems...  :-P

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

SHOULD rather than MUST sounds reasonable.

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

A minor technical point, but http:/foo.bar/baz.png with only one /
after the http: is valid, and is a relative URL looking for a baz.png file
in the /foo.bar directory on the current host. One can also use
http:baz.png to look in the current directory. This doesn't change your
point though, since it would almost certainly be a typo in this case.
That said, that could be a path to someone else's avatar image on the
same server, so there's a possible security issue to ponder.

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

Eep...

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

Hm, given the above, we may have to think some more about that.

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

Maybe we should discuss support for mode plugins? I think the mode
was originally only there so one could still have an avatar image
without uploading anything, but I may be wrong (François?)

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

I agree in principle, bearing in mind we will have to think about folks
potentially faking IDs by blindly redirecting.

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

Bring it on IMO, it's 15 years overdue! :-)

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

With all that RFC MUST SHOULD MAY etc. I agree. In fact, perhaps we
should write it up as an RFC :-) I'm happy to give it a crack. We should
use Sphinx. Sphinx is ace.

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