Drop "/{username}.png" in favor of "/user/avatar/{username}"

[6543]

the user pattern "*.png" was never reserved, so we either have to reserve it or drop the path.
I propose to drop the path in favor of an alternate one

for the full dialog read #23874 (comment)

alternative / close #23992

[techknowlogick]

users that end in *.png will already be broken, so we should add a blocker to prevent new users from creating such users. that wouldn't be a breaking change.

[techknowlogick]

I had read that, but am still preferring to add the *.png exclusion, as any user already created with that would be broken per the URLs routes. So by adding in the exclusion, then there is no breaking change, but by dropping the route it is a breaking change. I use that route somewhat regularly (at least once a month), and so that is where I am coming from.

[6543]

alternative -> #23992

[silverwind]

Do we know of any external integrations that use these endpoints? When were they introduced?

[6543]

this is no api so there was never a promise to not break ... btw.

[6543]

I personally don not have a strong opinion when it comes to either drop or reserve the png case ...

but would like to not see the reserve pattern list increase at all if it comes to new things ...

[silverwind]

I guess the ideal solution would be to keep supporting it and just be more intelligent during the routing. Assuming users user and user.png exist:

• /user.png -> return avatar of user
• /user.png.png -> return avatar of user.png

That could be done for all these endpoints and it would not be breaking.

[silverwind]

Ah, I see that can't work because we shadow the user page with such a route.

[silverwind]

I guess I prefer to add to reserved users, just to not break any existing integrations.

[silverwind]

I guess a /avatar/{username} may still be nice to have for future SVG avatars where a /avatar/{username}/{size} route does not make sense.