Since last week, there seems to be a new bug with the teamslogon.aspx redirection service.
It seems to double encode the provided url, redirecting to an invalid url and resulting in a 404.
Exemple:
https://contoso.sharepoint.com/sites/ContosoNet/_layouts/15/teamslogon.aspx?SPFX=true&dest=/sites/ContosoNet/Home%20page.aspx
will redirect to
https://contoso.sharepoint.com/sites/ContosoNet/Home%2520page.aspx
See the double encoding with the "Home%2520page" above.
The impact is that you can no longer provide to the teamslogon.aspx an url containing a space or any special character.
This will result in a redirect to an invalid url and a 404.
Thank you for the insights on the document. I am able to reproduce the issue, I have raised a bug and concern team is working on it.
I just noticed that there is a warning message pops up when I view my mootool.js script on FireFox browser.
The warning message is
The character encoding of the plain text document was not declared.
The document will render with garbled text in some browser
configurations if the document contains characters from outside the
US-ASCII range. The character encoding of the file needs to be
declared in the transfer protocol or file needs to use a byte order
mark as an encoding signature.
does that mean I have to add a Charset or something? but it is a script!!
Is there a solution for this?
In your HTML it is a good pratice to provide the encoding like using the following meta like this for example:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
Note: if any line between <head> and this meta line (Even if it's a
commented note) problem will remain, so make sure you added meta line
after <head> directly
But your warning that you see may be trigged by one of multiple files. it might not be your HTML document. It might be something in a javascript file or css file. if you page is made of up multiples php files included together it may be only 1 of those files.
I dont think this error has anything to do with mootools. you see this message in your firefox console window. not mootools script.
maybe you simply need to re-save your html pages using a code editor that lets you specify the correct character encoding.
FireFox is reporting that the response did not even specify the character encoding in the header, eg. Content-Type: text/html; charset=utf-8 and not just Content-Type: text/plain;.
What web server are you using? Are you sure you are not requesting a non-existing page (404) that responds poorly?
Check your URL's protocol.
You will also see this error if you host an encrypted page (https) and open it as plain text (http) in Firefox.
For HTML 5:
Simply add to your <head>
<meta charset="UTF-8">
If you are using ASP.NET Core MVC project. This error message can be shown then you have the correct cshtml file in your Views folder but the action is missing in your controller.
Adding the missing action to the controller will fix it.
I fixed this issue by adding a slash at the beginning to my relative path
In my case in ASP MVC it was a method in controller that was returning null to View because of a wrong if statement.
if (condition)
{
return null;
}
Condition fixed and I returned View, Problem fixed. There was nothing with encoding but I don't know why that was my error.
return View(result); // result is View's model
I got this error using Spring Boot (in Mozilla),
because I was just testing some basic controller -> service -> repository communication by directly returning some entities from the database to the browser (as JSON).
I forgot to put data in the database, so my method wasn't returning anything... and I got this error.
Now that I put some data in my db, it works fine (the error is removed). :D
I faced this issue in ASP.NET Core. In my case, it was caused by a missing appsettings.{Environment}.json file.
I had recently changed the environment to Production, but did not have an appsettings.Production.json file. The missing file caused a 500 Server Error which resulted in the character encoding browser message.
I got this error while working with live server in vs code.
Probably this error was because the the the default path for "proxyUri" was "null" in settings.json of live server file.
Solution was this was to set "false" as value for the "enable" key in "liveServer.settings.proxy"
If anyone is using SQL and they have meta tags there and still the error is shown, this happens because of your connection from .net to SQL.
In you appsettings.json update your connection string to have: Persist Security Info=True. So your connection string should look like this:
"DefaultConnection": "Server=[[server]];Initial Catalog=[[db]];Persist Security Info=True;User ID=[[user]];Password=[[pass]];MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
i faced the issue when moving to the next page in a table then clicking a button on the table...an easy fix is calling
$(function () {
$('#tableid').DataTable();
});
inside document.ready not outside
I'm developing a webservice written in C and hosted by a RedHat 6.3 box. The box locale is fr_FR.UTF-8.
When I curl my webservice from the command line, I can read text content contaning accents on the command line.
However, when I check the WS output through the Chrome Developer tools and in the webpage output, the accents are replaced by a square containing an interrogation mark.
The content type of the webservice output is application/json; charset=utf-8.
The webpage charset is utf-8, browser is in autodetect.
What did I miss that unables me to properly display accents with utf-8 ?
I solved this by checking the way the accented content was generated. Actually mine was generated by Postgresql, whose configuration parameter client_encoding was set to ascii, un changed client_encoding to 'UTF8', thsi solved my issue.
I have an element in a web page containing a UTF-8 encoded filename URL
<A HREF='http://server/site/%E8%A8%82%E8%B2%A8%E6%97%A5%E7%B5%90%E5%A4%B1%E6%95%97.txt'>訂貨日結失敗.txt</A>
This returns a 404 page from IIS. The file exists in the correct location on the server.
When I monitor what IIS is looking for using ProcMon, I can see it attempting to find a file that looks like the raw bytes from the UTF-8 string rather than the UTF-16 (?) string.
Ȩ‚Ȳ¨Æ—¥ÇµÅ¤±Æ•—.TXT
I'd have thought IIS would have done the UTF-8 to UTF-16 conversion to look for the filename on the server.
Any ideas where I'm going wrong.
Ta,
J
Looks like I need to use IIS 6 as a minimum. I've just tested it and it seems to work OK. msdn.microsoft.com/en-us/magazine/cc301710.aspx
I am seeing strange redirect behavior with URLs that have encoded characters. For example, the following two URLs differ ONLY by the case of the "e/E" in the first encoded character (i.e. "%e2" versus "%E2").
URL 1: http://youlookfab.com/welookfab/topic/your-favourite-80%e2%80%99s-music-bands
"200 OK" HTTP status, page loads fine
URL 2: http://youlookfab.com/welookfab/topic/your-favourite-80%E2%80%99s-music-bands
causes a "302 Found" redirect
in a browser, the page redirects to the correct URL above (lowercase "e")
using web-sniffer.net, the content length is zero
I originally started looking into this because Google Webmaster Tools was showing crawl errors ("Redirect error", to be specific) on a bunch of pages that had URL encoded characters. Although my sitemap file specifies these characters in lowercase, GWT is showing them in uppercase.
I can't see any reason in .htaccess for lowercase URL encoded characters to redirect to uppercase. The site is based on bbPress, and I don't see any reason in the bbPress code for this to happen either.
Could mod_rewrite be doing something strange? I know there was a bug in the past where URL encoded characters were handled incorrectly.
Any insight you have would be much appreciated.
[This is an integrated bbPress/WPMU installation running LAMP, hosted on a MediaTemple (dv) server]
After digging deeper I found that the redirect was actually happening inside bbPress, which detects the uppercase hex in the incoming URL and sees that as a discrepancy with the "correct" permalink (which has lowercase hex).
I have written this up in a little more detail, along with a simple bbPress plugin to address the issue, at http://theblogeasy.com/2009/12/26/bbpress-and-encoded-urls-with-uppercase-hex/
Regarding the Google crawl error... my theory is that this is caused when the crawler (which converts encoded URLs to uppercase hex) and bbPress (which redirects them to lowercase hex) get into an infinite loop. The crawler probably detects this condition when it gets the same URL back repeatedly and throws an error.