get request params URI encoding #1111
Comments
|
Can you have provide an example of the data that failed encoding before you commented this line out? |
|
view : { spaces in filter value |
|
Did the issue only occur in the Can you provide the final URL before and after commenting out the line? |
|
Thanks. Do you have any information on the server that didn't accept the |
|
Server: Apache/2.4.27 (Win64) OpenSSL/1.1.0f I apologize for the fact that unwittingly misled you. The problem is not the HTTP server. The problem is in the app's library. Not all libraries applications follow the recommendations www.w3.org. It's ironic, but the variant with %2B instead of + , allows for higher compatibility with all libraries. |
|
I assume that you mean Looking at the RFC-3986 standard for URIs there's the following information in 2.3: gen-delims being reserved in the path of the URI and sub-delims being reserved after the |
|
|
I'm facing a similar issue in which I'm making a GET request to a legacy server that doesn't accept |
|
To answer my own question, I found out about Lines 5 to 13 in ae218d0 and Lines 35 to 58 in ae218d0 This led me to implement my own version overriding the encoder and bypassing some of the util functions as I'm working on TS and nodejs and I can use some built in alternatives: function encode(val: any) {
return encodeURIComponent(val)
.replace(/%40/gi, '@')
.replace(/%3A/gi, ':')
.replace(/%24/g, '$')
.replace(/%2C/gi, ',')
.replace(/%5B/gi, '[')
.replace(/%5D/gi, ']');
}
function customSerializer(params: any): string {
return Object.keys(params)
.map((key: any) => {
var val: any = params[key];
if (val === null || typeof val === 'undefined') {
return;
}
var keyName = key;
if (Array.isArray(val)) {
keyName = key + '[]';
} else {
val = [val];
}
return val
.map((v: any) => {
if (Object.prototype.toString.call(v) === '[object Date]') {
v = v.toISOString();
} else if (v !== null && typeof v === 'object') {
v = JSON.stringify(v);
}
return encode(key) + '=' + encode(v);
})
.join('&');
})
.join('&');
} |
|
You're violating the spec here, at least current ones from what I see. Axios broke what was working in jQuery so I think it's safe to say that you should use %20 as it's most compatible regardless of what old specs say about + being used for URLs. https://stackoverflow.com/questions/2678551/when-to-encode-space-to-plus-or-20 |
|
I just realized that you set this and it's not Axios itself. Sorry my misunderstanding in how things work. You can ignore my comment, and really the issue is Qs.stringify. Since you can set a custom serializer, this issue isn't Axios anyways. Sorry if I wasted your time on this. I think you can actually close this as it's not an Axios bug at all. |
|
I guess
Is this a typo or intended? Line 11 in 2ee3b48 |
|
Same issue here |
|
Same issue with |
|
Created PR #2563 to fix this and other similar issues. |
|
On this I don't think this should be implement as mentioned previously if you'd like to use another format, you can set a custom paramsSerializer as follows: axios.defaults.paramsSerializer: function(params) {
// return a query string
}Using the qs library: axios.defaults.paramsSerializer: function(params) {
return qs.stringify(params, { indices: false }); // param=value1¶m=value2
} |
Indeed we can use a custom paramsSerializer to use RFC 3986, however I believe it should be the default, because latest web servers won't accept RFC 1738 encoded params, however old servers should accept RFC 3986 (at the very least the %20 encoding for spaces is backward compatible). Using a custom paramsSerializer must be done every time we use axios, so it's quite error prone imo. |
#### Summary
function encode(val) in buildURL.js
encodes spaces as '+'
this is wrong, because not all http servers decodes '+'
I comment line out and it working for me.
function encode(val) {
return encodeURIComponent(val).
replace(/%40/gi, '@').
replace(/%3A/gi, ':').
replace(/%24/g, '$').
replace(/%2C/gi, ',').
// replace(/%20/g, '+').
replace(/%5B/gi, '[').
replace(/%5D/gi, ']');
}
#### Context
The text was updated successfully, but these errors were encountered: