These URLs are a bit weird. I don't think "probs" is an appropriate page title, something like API:SessionStorage/Errors#<code> would be more natural IMO.
Topic on Talk:Requests for comment/SessionStorageAPI
For what it's worth, that URL was meant more or less as a placeholder; We should definitely establish something more appropriate.
The idea here is that the problems could be described uniformly across services, hence the generic name. That said, I agree "probs" is probably a bit arbitrary, but I wouldn't specifically create error pages just for this service.
Thinking out loud, but if we can describe them uniformly across all services, then I wonder what the point is? It would seem redundant to put up a page somewhere to describe what has been thoroughly described elsewhere, (a 404 Not Found, for example). It seems like this is only useful if we're able to expound on the meaning of an error in the context of a specific service.
Currently there's no apparent standard between different services on how to report errors.
- Parsoid just returns an HTML with 'cannot GET' for a 404 for example. This should probably be fixed.
- RESTBase is returning a JSON error with a type property somewhat like https://mediawiki.org/wiki/HyperSwitch/errors/not_found
- event streams return a JSON with a type property just not_found
- ORES returns fairly big HTML if the route is not found, 404 with JSON non RFC7807 compliant response if the project is not found, and a 200 with a complex JSON structure where for every score it says 'RevisionNotFound'.
I have only looked into this subset of services, and I've only looked into 404 errors. The question regarding errors format have been raised before, I've filed task T209164 in order to bring other node services to the standard, but after looking more deep into this I believe the scope of the task has to be expanded.