When launching an LTI 1.3 Resource link, forward slashes (and perhaps other characters) in a target URL's fragment identifier double encode when posting to a tool provider's login initiation URL. Unsure whether it's being stored this way on Deep Linking return, or if it's being produced that way as part of the LTI launch.

To reproduce:

1. Go through a LTI 1.3 deep linking process that returns a content item whose target URL contains a fragment with a forward slash (for example, [https://learn.comptia.org/app/certmaster-learn-and-certmaster-labs-for-a-core-1-exam-220-1101#quiz/details/categories/12345|https://learn.comptia.org/app/certmaster-learn-and-certmaster-labs-for-a-core-1-exam-220-1101#quiz/details/categories/12345[]
2. Launch the Resource link placed
3. Using the example URL above, the payload of the login initiation POST to the tool provider is "https%3A%2F%2Flearn.comptia.org%2Fapp%2Fcertmaster-learn-and-certmaster-labs-for-a-core-1-exam-220-1101%23quiz%252Fdetails%252Fcategories%252F12345". This is passed along the entire LTI login and launch exchange, until finally the user winds up at a link that doesn't match the originally intended destination.

What I expect:

Decoded target link of the login initiation POST matches the link returned by the Deep Linking content item return, and the LTI launch process completes as normal.

What happens:

Forward slashes in fragment identifiers of the target link are double encoded. This makes it through the entire LTI login process, but at the end of the launch, it sends the user to a URL with a percent-encoded fragment, which either breaks, or ends up redirecting the user to a default home page for that fragment rather than the intended destination.

Thank you!