What you're experiencing is correct behaviour and is called URL encoding. HTTP requests have to conform to certain standards. The first line is always made up of three parts delimited by a space:
- Method (GET, POST, etc.)
- Path (i.e. /api/lol/na/v1.4/summoner/by-name/the%20man)
- HTTP version (HTTP/1.1, HTTP/1.0, etc.)
This is usually followed by HTTP headers which I'll leave out for the time being since it is beyond the scope of your question (if interested, read this https://www.rfc-editor.org/rfc/rfc7230). So a normal request looks like this:
GET /api/lol/na/v1.4/summoner/by-name/the%20man HTTP/1.1
Host: na.api.pvp.net
User-Agent: Mozilla
...
With regards to your original question, the reason the library is URL encoding the space to %20
is because you cannot have a space character in the request line. Otherwise, you would throw off most HTTP message parsers because the man
would replace the HTTP version line like so:
GET /api/lol/na/v1.4/summoner/by-name/the man HTTP/1.1
Host: na.api.pvp.net
User-Agent: Mozilla
...
In most cases, servers will return a 400 bad request response because they wouldn't understand what HTTP version man
refers to. However, nothing to fear hear, most server-side applications/frameworks automatically decode the %20
or +
to space prior to processing the data in the HTTP request. So even though your URL looks unusual, the server side will process it as the man
.
Finally, one last thing to note. You shouldn't be using the String.replace()
to URL decode your messages. Instead, you should be using decodeURI() and encodeURI() for decoding and encoding strings, respectively. For example:
var user = getUrlVars()["username"].replace("+", " ");
becomes
var user = decodeURI(getUrlVars()["username"]);
This ensures that usernames containing special characters (like /
which would be URL encoded as %2f
) are also probably decoded. Hope this helps!