libravatar-fans team mailing list archive

[Tristan Le Guern <tleguern@xxxxxxxxxxx>]

Thanks for your inputs.

Le 23/11/2018 à 20:58, Francois Marier a écrit :
> In general, I think we should always return an image. That's what the
> clients are expecting.
While it makes sense I think it is also brittle as the API is not future 
proof. I am not sure it is an important property though.

> > * What to do if the size option is supplied but has no value ?
> > * What to do if the size option is supplied but the value is not an integer?
> > * What to do if the size option is supplied but the value is 0 ?
> >
> >    + ivatar and libravatar both return an avatar of the default size ;
> >    + libravatar.cgi returns the HTTP status code 400.
>
> I think it makes sense to do the best we can here and return something to
> clients that don't do proper error-checking on their end (e.g. a piece of
> software that includes Libravatar support and lets admins configure the
> avatar size to any value).

So ignoring the size parameter entirely if it is invalid or empty seems 
to be favoured. This is also partially what Gravatar does (it has its 
own quirks like returning a 1 pixel sized image if the value is negative 
or gibberish but the regular size if the value is 0).

> > * What to do if the size option is supplied but the value is negative ?
> >
> >    + ivatar crashes (issue #21) ;
> >    + libravatar returns an avatar of the default size ;
> >    + libravatar.cgi returns the HTTP status code 400.
>
> I imagine ivatar will fix the crash and match the libravatar behaviour here.

Yes, it should be fixed in the git repository but the running instance 
is still crashing.

> > * What to do if the size option is supplied but the value is too big ?
> >
> >    + ivatar returns an avatar of the maximum allowed size (512) ;
> >    + libravatar returns an avatar of the requested size ;
> >    + libravatar.cgi returns the HTTP status code 400.
>
> ivatar's behaviour seems ideal here.

Oliver rightly corrected me here. Ivatar returns directly an avatar of 
the maximum allowed size while Libravatar /redirects/ to an avatar of 
the maximum allowed size. This second behaviour is also what Gravatar is 
doing, albeit with a different maximum (2048).

> > * What to do if the default option is supplied but has no value ?
> > * What to do if the default option is supplied but has an unhandled value
> > (such as d=unicorn) ?
> >
> >    + ivatar and libravatar both return the user's avatar ;
> >    + libravatar.cgi returns the HTTP status code 400.
>
> Again, I think it makes sense to do the best we can when the API is
> accidentally misused by a client.
Gravatar has a specific quirks here: if the default parameter has an 
invalid value such as "unicorn" but the hash matches a user then it is 
ignored, otherwise it returns a HTTP status code 400. I really think 
this is the worst behaviour as the result is not consistent.

> > * What to do if the default option is supplied but has an unhandled value
> > (such as d=unicorn) and the forcedefault option is set to true ?
> >
> >    + ivatar returns an HTML document, the home page ;
> >    + libravatar doesn't implement forcedefault ;
> >    + libravatar.cgi returns the HTTP status code 400.
>
> Following the principle of being tolerant of bad configurations, I guess we
> should ignore the invalid value and just use the "default" page we would use
> if the "d" option wasn't specified.
If we have a mechanism to retrieve valid values for the default 
parameter then it is okay for me to ignore invalid ones.

So to summarise:

* empty parameters must be ignored ;
* values for the size parameter must be integer ;
* values smaller than the allowed minimum for the size parameter must be 
ignored ;
* values greater than the allowed maximum for the size parameter must be 
replaced with this maximum ;
* unknown values for the default parameter must be ignored.

Does everyone agree ?