I think that error message should include the param name (cursor) that couldn't be parsed.
Agreed ... the current error text is basically just a placeholder, ideally it should be something like...
Unable to parse cursor param: value must either be '*' or the cursorContinue value from a previous search: NOK
Also, maybe it would be useful to include a prefix that will (probably) never be used in unique ids, to visually identify the cursor as such: like always perpending '*'?
Hmmm, I'm not sure if that's really worth the added bytes & parsing.
If folks really felt like the param name should be "searchAfter" then i could certainly see the value in having some clear prefix, since the param name might lead folks to assuming they know what hte input should be; but with "cursor" i don't think we need to worry as much about people assuming they know what to put there, and with a clear error message instructing people how to get a valid cursor (from cursorContinue), that seems good enough. (right?)
the Base64-encoded text is used verbatim, including the trailing padding '=' characters - these could be stripped out for external use (since they're there just to make the string length divisible by four), and then added back before Base64-decoding. In a URL non-metacharacter '='-s look weird, since they're already used to separate param names and values.
Interesting idea ... again: i'm not sure how i feel about the added overhead to the parsing just to shorten the totem – especially since clients will always need to safely url encode anyway since Base64 strings can also include "+"
In the current patch, I used the base64 utility class Solr already had (used by BinaryField and a few other places). But your suggestion reminds me that commons codec's Base64 class (jar already used by solr) supports a "url safe" variant of base64 (which looks like it's defined in RFC 4648?)...
...something to consider.
One other comment i got from a coworker offline was why I liked cursorContinue instead of nextCursor or cursorNext. My thinking was that since 'cursor', (as a concept) is a noun, "next cursor" might suggest that it was a (different) cursor then the one currently in use. I don't want people to think these strings are names of cursors, and they re-use the same name until they are done with it. I want to make it clear that to continue fetching results from this cursor, you have to specify the new value.
Would "cursorAdvance" convey that better then cursorContinue ?