Query parameters are not escaped properly, e.g. a colon : is not escaped in query parameter values.
Actual
Expected
http://api-latest-master.openapi-generator.tech/api/gen/clients/typescript-angular
: into some query string valueRevert "Don't escape [ and ] in query param keys"
Fix encoder.mustache
Before
import { HttpUrlEncodingCodec } from '@angular/common/http';
/**
* CustomHttpUrlEncodingCodec
* Fix plus sign (+) not encoding, so sent as blank space
* See: https://github.com/angular/angular/issues/11058#issuecomment-247367318
*/
export class CustomHttpUrlEncodingCodec extends HttpUrlEncodingCodec {
encodeKey(k: string): string {
k = super.encodeKey(k);
return k.replace(/\+/gi, '%2B');
}
encodeValue(v: string): string {
v = super.encodeValue(v);
return v.replace(/\+/gi, '%2B');
}
}
After
import { HttpParameterCodec } from '@angular/common/http';
/**
* CustomHttpUrlEncodingCodec
* Workaround for https://github.com/angular/angular/issues/18261
*/
export class CustomHttpUrlEncodingCodec extends HttpUrlEncodingCodec {
encodeKey(k: string): string {
return encodeURIComponent(k);
}
encodeValue(v: string): string {
return encodeURIComponent(v);
}
decodeKey(k: string): string {
return decodeURIComponent(k);
}
decodeValue(v: string): string {
return decodeURIComponent(v);
}
}
the solution you propose makes sense
@JohannesHoppe @akehir what do you think?
I wonder if we should provide a facility to configure this, as I can image different projects having varying requirements (depending on the backend framework). In other words, we could have the encoder being injected into the api.
In general, however, the solution as proposed should be better than the angular default behaviour, though it might be a minor breaking change for some projects.
@cubidobusinesssolutions would you like to implement a runtime configuration option to pass a custom HttpParameterCodec if needed?
@cubidobusinesssolutions would you like to implement a runtime configuration option to pass a custom HttpParameterCodec if needed?
Ok, I will do it.
Most helpful comment
I wonder if we should provide a facility to configure this, as I can image different projects having varying requirements (depending on the backend framework). In other words, we could have the encoder being injected into the api.
In general, however, the solution as proposed should be better than the angular default behaviour, though it might be a minor breaking change for some projects.