libravatar-fans team mailing list archive

[Francois Marier <francois@xxxxxxxxxxx>]

On 2012-08-01 at 23:13:58, Christian Weiske wrote:
> 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. 

Ok, the only problem I can see here is that some people might be using
invalid hashes to show what the defaults look like.

Once we fix this bug:

  https://bugs.launchpad.net/libravatar/+bug/811603

then we could look into returning 400s. Would you like to file a bug for
this 400-on-invalid-hashes?

> 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.
> 
> If it does not match "^[a-z0-9]+$", redirect to that supposed URL. Done.

Either that, or we have a register of allowed default URLs that third-party
implementations can either support or ignore.

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

I'd say that servers shouldn't validate the URI, just 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.

Well, maybe, but I don't see the point of having those if you're the only
implementation that does it?

As a third-party implementer, you could certainly choose to return generated
ponies instead of a nobody icon for your domain.

So I guess I don't really see the use case for extensions to the general
default URLs.

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

If I understand spdy correctly, I think you only get it when you ask for
HTTPS. And the URL scheme is still "https". So I'm not sure we need to do
anything at all to allow it.

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

Yes, it would be great to have slick explanations like http://avatars.io/

Cheers,
Francois

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