Current State

Since messaging destinations are delimited by "/", the existing code performs a simple string replacement of "/" -> "%2F" in usernames. This allows usernames which contain "/" to be used and have messaging destinations parsed correctly. See SimpMessagingTemplate.java and DefaultUserDestinationResolver.java

Issue with Current State

Usernames that already contain "%2F" end up with that character sequence converted to a "/" by DefaultUserDestinationResolver. E.g., abc%2Fabc > abc/abc; however, abc/abc is not the username, so destination matching fails.

Here is an example test that fails, resulting in

org.springframework.messaging.simp.user.DefaultUserDestinationResolverTests > handleMessageEncodedUserNameWithPercentTwoEff() FAILED
--
org.opentest4j.AssertionFailedError at DefaultUserDestinationResolverTests.java:205
 
717 tests completed, 1 failed

:spring-messaging:testorg.springframework.messaging.simp.user.DefaultUserDestinationResolverTests » handleMessageEncodedUserNameWithPercentTwoEff() (0.044s)
org.opentest4j.AssertionFailedError: 

Expecting:
 <0> (instead resolves to 0 destinations)
to be equal to:
 <1> (should resolve to a single destination)
but was not.

(Gradle build scan)

Possible Solutions

1. Use a custom encoding scheme that accounts both for "/" and whatever "/" encodes to in the scheme.
2. Use a known encoding scheme like application/x-www-form-urlencoded or URL-safe Base64 (RFC 4648) and either:
   (a) Encode all usernames
   (b) Encode only usernames that contain characters that need to be encoded and flag the username as encoded so that only encoded usernames are decoded

Sample Solution

A sample solution is included in this pull request using 2(b).

Outstanding Questions

Should an explicit encoding be provided for String > byte[] and byte[] > String? If so, what? UTF-8? Or just let the behavior be undefined if running Java in an environment where the default encoding does not support a particular character?

Other Alternatives

• Document "%2F" as not supported in a username and add a runtime check for invalid user names instead of the current behavior of just not matching message destinations correctly

Any feedback is appreciated!

As a note, I recreated this pull request since I didn't branch my fork of the code first or squash commits as recommended by the contribution guidelines.