Bug caused by user name non alpha chars

Although in firefox browser there is no error code returned. It just hangs and shows an empty page.

In firefox you can open the Developer tools and check the Network tab, it lists every network request along with the full server response, you can see there if you actually got a 410 and the UI just didnt show it

Wow ... even copying from a .txt file opened in the browser I can't get the URL to not have the emoticon without work and manually editing the link:

https://www.chess.com/member/jg%3A%29

https://api.chess.com/pub/player/jg%3A%29 doesn't work, so api.chess.com is not expecting URL encoding to be applied.

Giles, I think it may be a more fundamental problem than even that when it comes to the endpoint request? If you take a look at my post #13, I managed to insert the correct username in its literal form in the API URL but the c.c servers still rejected the endpoint request with a 410 error response.

I suspect this is a problem of the developers' own creation? It looks as the algorithm used to permit the selection of that username for ordinary web-page use, is different to the one used to filter API type URL's. That would explain why I can link to this member's web profile page (using a link from an external web page) but I can't access their equivalent endpoint.

The problem we're all having with even posting the correct web URL is a distraction I think - something created by the design of the post-editor which automatically converts ':'')' into

What I don't understand is how that user was ever allowed to select that combination of characters in the first place? I use quite a large look-up table of members' usernames & looking through it, it strikes me just how conservative the choice of characters is - none apart from strictly alphanumerics, hyphens & underscores.

Look around the site & try to find anyone with a username that doesn't conform to that narrow set of characters! I'm just thinking aloud but unless that rule has been greatly relaxed in V3, I think a bug might have allowed that user to select a (normally) prohibited name-string?

I thought the reverse, Stephen. My understanding was that the username choice was being more restrictive (to sensible characters), so I think it is a bug which allowed this one to slip through.

My member search routine now crashes daily if Mr. JG-HappyFace has logged on.

Trying to decide if an error trap for the name is worth the effort.

More restrictive? But T_D, can you find any other member on the site that has the ':' or ')' symbols in their username? Isn't it the case that this hasn't been a problem before because no new members were allowed to select such symbols for their usernames before recent months?

Agree Stephen. I think it must be a bug for this one account

Dear @Tricky_Dicky we are verifying the issue. That username shouldn't be allowed and that's why PubAPI is returning a "401" . We are currently investigating why this username slipped through the validation rules.

Thanks Andrea. That was our conclusion.

That had become the only explanation left that made any sense. The worrying thing is - how many other members are there who might have circumvented the same naming rules & have usernames that are going to cause problems for API users in the future?

The practical question is how this (recent) member was allowed to choose this username and what to do about it, which Andrea is looking into.

The wider question for me is "Should member names (and club names, and any other names) as part of RESTful api.chess.com URIs be URL-encoded?" (Or is that URI-encoded?) I think the answer might be "Yes, but there should not be member names or club names that need encoding."

"Yes" because requests are URIs and "no" because neither side (client or server) wants the hassle of URIs that need encoding.

Andrea, any comments very welcome.

The number of recent players with not valid usernames is very limited and we will contact them to restore a proper username.

@skelos at this moment, since we use transliteration for club and tournament urls and player usernames do not allow special chars encoding is not necessary.

Thanks Andrea.

I hadn't appreciated the distinction myself but this makes interesting reading..

https://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn

this extract relates specifically to this discussion...

"

Does the difference between URL and URI have anything to do with what characters are permitted?

No. URLs are defined to be a strict subset of URIs. If a parser allows a character in a URL but not in a URI, there is a bug in the parser. The specs go into great detail about which characters are allowed in which parts of URLs and URIs. Some characters may be allowed only in some parts of the URL, but characters alone are not a difference between URLs and URIs.

"
So you might expect the site parser to take care of that & disallow any invalid characters or symbols?

But when it comes to deriving club URL/URI id's, the site follows it's own method from what I've seen. For example:-

Ajedrez en Español is rendered as ajedrez-en-espantildeol (notice the tilde in the name)
Independència becomes independegravencia
ΙRANIAN becomes  iotaranian (this one caused me a headache at first but the initial 'I' is actually the Greek Iota)
"MONIKA" becomes quotmonikaquot

I assume those transliterations are site-specific?

The subtle differences between URLs and URIs I struggle to keep straight.

[Edit: I understand it whenever I read it; it's not difficult. Just seldom relevant so I forget again!]

Possibly my terminology is wrong above ... but for our purposes, as Andrea has stated, due to transliteration of account and club names encoding should not be required for endpoints. Good enough for me!

Not helped by the fact that the w3c spec. refers to 'should not' rather than shall or must not when considering certain symbols?

But I agree, this is one for the development team to sort out & if we get program crashes in the meantime, then code for the exceptions. At least we understand what the problem is.

 hey gays