URLs Containing Special Characters Break Entire Sites If Directly Opened After A Browser Restart

Browser Support Mobile Support
1

The post has been massively overhauled to correct old information with newly discovered data.

Description of the issue:
For some reason directly visiting a URL that contains special characters after a browser restart via a URL paste, bookmark, history, link, etc, renders portions of an entire site completely unusable unless you restart the browser and navigate to that page manually using links on the web site’s home page first. If you try to directly access the link after opening Brave when it’s fully closed or after restarting it, Brave will modify something and cause 400 errors which can cripple the use of entire websites. This behavior persists even when clicking links that should work, such as “sign in”, until you restart the browser.

How can this issue be reproduced?

  1. Restart Brave, then visit https://lightsail.aws.amazon.com/ls/webapp/us-east-2/instances/TeleTab_2.0/connect?# in either desktop or mobile mode. It doesn’t matter which. It’s a link I use to directly connect to my VPS console. It should lead to a login page if it works.
  2. If that loads a 400 error, Brave broke it.
  3. Sometimes it might work as intended and send you to the login. If it does just close the tab, close (swipe it out of recent apps) Brave, relaunch Brave, and revisit that URL (I do it through a bookmark). You’ll get the 400 error.

The next part of this bug is that whatever Brave did to break that page will persist across the entire affected site, in this case AWS pages requiring a login, and completely break it. It can be observed by continuing below:

  1. Press the AWS logo in the top left to be taken to the main page.
  2. In the top right, press “Sign in”.
  3. This should lead to another 400 error. Again, this will persist across any part of the site that requires a login until Brave is restarted. Restarting fixes the persisting 400 error unless you visit the link I provided again, which will cause it to return.

To prove that this is in fact an issue with Brave and special characters in the URL, and not AWS’ fault, the following steps show that the link is valid and AWS is properly handling it.

  1. Restart Brave, then visit aws.amazon.com in desktop mode to simplify things.
  2. Click “sign in” in the top right if in desktop mode.
  3. When the login page shows, close the tab. This probably eliminates some variables for the next step. The next step will still work if done in the current tab.
  4. Open a new tab, then visit the link I provided in step 1 with the special characters in it. https://lightsail.aws.amazon.com/ls/webapp/us-east-2/instances/TeleTab_2.0/connect?#
  5. The link will correctly redirect to the login page no matter how you open it be it bookmark, link click, URL paste, etc. This proves the link is valid and working. It will now work every time no matter how you open it. But if you close the tab and restart Brave, then try to visit the link again, the entirety of AWS will once again be broken with 400 errors.

This places all blame on Brave and not AWS.

Expected result:
Prior to modifying this post, someone mentioned they were sent to a similar looking URL that correctly lead to the login page. I tried to reproduce the bug with that link and indeed could not get it to trigger until I finally tried again using the bookmark that includes my server name in the URL. Thus the link has been updated to include it, and the post updated with fresh information.

Steps 7-11 are how the browser should behave, except I shouldn’t be required to do that in order to get into my VPS console. The link should be able to be opened directly after a fresh browser start without breaking the entire site.

Brave Version( check About Brave):
1.32.106, but it’s been happening for a long time now.

Mobile Device details
Samsung Galaxy Note 20 Ultra on Android 11.

Additional Information:
The new link that includes my server name does work as intended in Firefox. It’s not invalid. If I’m already logged in I can visit that link without failure and always be sent right into my VPS console with it. But when I first launch the browser, because I need to quickly access the VPS I have it bookmarked, it’ll trash the entire site with the error 400 bug unless I perform steps 7-11 first. I think it’s the special characters doing it, so really it affects any link with special characters in it if that’s the case.

Here’s a video of the behavior. Between keeping the file size small enough to upload here, the quality legible enough to read, and editing the extra details out, the best solution was to just do a crude edit straight from my phone gallery to cover up sensitive information. That’s what the purple spots are. Editing them to only appear when they’re needed made the file size way too big. Seriously guys, 4 MB is way too small.

2

This is incredibly obnoxious and prevents me from accessing my VPSs.

Tagging @Mattches because I’m unsure who else is involved with the Android browser.

3

@Wiggly,
I’m not able to reproduce this issue (using Samsung Galaxy S9+) and, further, the URL I see displayed when I copy/paste the link you provided appears to be the same as the one in your video. Attempted in both desktop mode and mobile.

I’m actually wondering if it has something to do with the Galaxy device you’re using, rather than Brave itself. I’m going to reach out to Android team about this but in the meantime, if you use the mobile version of the site to visit the URL, do you get the same results?

4

@Mattches
Yes, it does that on the mobile site too.

Upon further investigation it seems the name of my server is part of the issue. Either that or the pound sign, period, underscore, all of the above? I omitted it from the URL in the OP because on my end the bug was already present, so the link I provided lead to a 404 error and I overlooked that as thinking it was a valid trigger. But as I mentioned in the OP, any link is a trigger once it begins. My mistake.

On that note, try repeating the steps using this link instead. This is the link I use to connect directly to one of my VPS consoles without having to go through a dashboard of different instances first. A shortcut if you will. For anyone other than myself with my login, it won’t lead to a valid VPS instance. But in the interest of this thread, it seems to trigger the above mentioned bug.

https://lightsail.aws.amazon.com/ls/webapp/us-east-2/instances/TeleTab_2.0/connect?#

I’ve also discovered something further. The link provided, now that it’s the right link (I still think it’s the special characters), always causes the bug when visited after a browser restart. I’ve further discovered that if you visit aws.amazon.com after a browser restart, press “sign in” in the top right, then close that tab and visit the link I provided in a new one (or even the same one), the link correctly sends you to the login as it should. But if you try the link first before the login page after a browser restart, it breaks the entire website. This proves that it’s not AWS’ fault and it is in fact an issue with something Brave is doing to the website, otherwise the link provided would never work at all.

I’ve added this information to the OP and modified it to properly cover the scope of the bug now that it’s more understood on my end. You should give it another read because it might as well be a different thread with how heavily I modified it to correct and explain things.

6

@Wiggly,
Even with the updated instructions/link, I’m unable to reproduce the issue. I do not get a 404 error under any circumstances. Still waiting on a response from Android team – appreciate your patience.

7

@Mattches

Huh. That’s strange. Even when I do it in a private tab I get the 400 error. So it’s not a cookie or cache issue. Weird. Could it be some browser setting toggle?

8

@Wiggly,
Not sure what setting that would cause this. You could try turning Shields down for the site just to test and see if this makes any difference.

9

Nope, the same behavior persists. But that did reveal something new and unrelated. I don’t know if it’s intentional or not, but shield settings don’t persist across a site’s subdomains. For example if I shut them off for amazon.com, they will still be on for aws.amazon.com. If they’re off for signin.aws.amazon.com, they’ll still be on for aws.amazon.com, lightsail.aws.amazon.com, etc, even though it’s all under the domain amazon.com.

10

Bumping so it doesn’t close.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.