New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
java.lang.IllegalArgumentException: Invalid character '[' for QUERY_PARAM in "match[]" #462
Comments
some things are encoded, others are not, is there a reason why? |
I reviewed the URL again and found that it is encoded like this intentionally. The value of parameter In
Maybe this case should be handled more specifically. |
I'm open to suggestions. Springs url handling expects all encoded or not at all |
I'm wondering that why a gateway check url so strictly? And any idea to fix this issue? |
I had a similar problem accessing a Typo3 backend through the gateway and made a filter fixing the encoding. It's not throroughly tested and though not pretty it seemed to work. I'm not using this in production and it's written in Kotlin but you might wanna have a look: class Typo3BackendFixFilter : GatewayFilter {
private val log = LoggerFactory.getLogger(this.javaClass)
override fun filter(exchange: ServerWebExchange, chain: GatewayFilterChain): Mono<Void> {
val req = exchange.request
ServerWebExchangeUtils.addOriginalRequestUrl(exchange, req.uri)
val uriComponents = UriComponentsBuilder.fromUri(req.uri).build()
val newQueryParamsMap = HashMap<String, MutableList<String>>()
uriComponents.queryParams.forEach { mapEntry ->
val newKey = if (mapEntry.key.contains("%")) mapEntry.key else URLEncoder.encode(mapEntry.key, "UTF-8")
val newValue = mapEntry.value.map { listEntry ->
listEntry?.let {
if (listEntry.contains("%")) {
listEntry
} else {
URLEncoder.encode(listEntry, "UTF-8")
}
} ?: ""
}.filterNot { it.isEmpty() }.toMutableList()
newQueryParamsMap[newKey] = newValue
}
val newURI = UriComponentsBuilder.newInstance()
.scheme(uriComponents.scheme)
.host(uriComponents.host)
.port(uriComponents.port).also { builder -> uriComponents.path?.let { builder.path(it) } }
.queryParams(CollectionUtils.toMultiValueMap(newQueryParamsMap))
.fragment(uriComponents.fragment)
.build(true).toUri()
val request = req.mutate()
.uri(newURI)
.build()
exchange.attributes[ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR] = request.uri
return chain.filter(exchange.mutate().request(request).build())
}
} |
Hi, Example URI: Gateway Scenario:
WebFlux raw controller scenario:
results with In summary, raw controller handles the partial encoding by the order of "="s. However, RouteToRequestUrlFilter passes the query params to HierarchicalUriComponents as encoded because of '%' in the sample URI. Since, HierarchicalUriComponents expects fully encoded parameters I think gateway should support these kind of cases to provide compatibility with Webflux, and this could happen in many situations. For example, chrome encodes the uri |
I have filed a pull request to handle this case. The basic idea is to treat partial encoded URI as uncoded URI. There are two cases which I can image to cause partial encoded URI.
Case 1) will be handled by java well. So just treat partial encoded URI as uncoded. And this patch works for me well. Web server application is out of my domain and correct me if I have made mistake. |
Ran into this issue trying to use Spring Cloud Gateway in front of JupyterLab. The JupyterLab UI makes a request with '=' in a query parameter value: 2018-08-17 16:46:02.085 ERROR 23572 --- [server-epoll-12] .a.w.r.e.DefaultErrorWebExceptionHandler : Failed to handle request [GET http://redacted.hostname.com:8080/steve1/jupyter/static/components/MathJax/MathJax.js?config=TeX-AMS-MML_HTMLorMML-full,Safe&delayStartupUntil=configured%22%20charset=%22utf-8%22] java.lang.IllegalArgumentException: Invalid character '=' for QUERY_PARAM in "configured%22%20charset=%22utf-8%22" at org.springframework.web.util.HierarchicalUriComponents.verifyUriComponent(HierarchicalUriComponents.java:417) ~[spring-web-5.0.8.RELEASE.jar:5.0.8.RELEASE] ... Would be awesome if the gateway would pass such requests along, since most other components don't seem to be bothered by this. |
I have the same issue, just like described above. In my case the query params always contain an URL with "=" in it. The target service alone can handle these requests without any problem, the gateway unfortunately not. It'd be nice, if you could push a fix for that or provide an official workaround. :) |
#467 to fix this issue, and this patch works well for me. |
Any update on getting this issue addressed? We have same issue on our project where our client urls are not fully encoded! they have "=" in query param values |
@spencergibb Any comments? |
@spencergibb Would you please consider fixing this behaviour which causes inconsistencies between the gateway and the webflux ecosystem? |
I've also encountered this issue and like to add a different perspective: The exception being thrown leads to a HTTP 500 Internal Server Error. In my opinion, a user should not be able to trigger a 500 error by typing an invalid URL into the address bar. I'd expect no error or a HTTP 4xx (i.e. 400 Bad Request) instead. |
@ferdinand-beyer I think that it shouldn't throw any errors at all since WebFlux is perfectly fine with these requests. |
I'v upgraded Spring-Cloud-Gateway to 2.1.1.RELEASE but issue still preset. I'm using Gateway as a proxy for Grafana, where request look like Configuration: spring:
cloud:
gateway:
routes:
- id: grafana
uri: http://grafana:3000
predicates:
- Path=/grafana/**
filters:
- RewritePath=/grafana/(?<segment>.*), /$\{segment} Request: Stacktrace:
|
Can you please open a separate issue? |
@ryanjbaxter yes of course |
…pring-cloud#462)" This reverts commit 59798f5.
Use gateway to forward grafana request get above error.
Seems the request
http://xxx.com/grafana/api/datasources/proxy/1/api/v1/series?match[]=jvm_classes_loaded%7Binstance%3D%22config%3A8888%22%7D&start=1533108081&end=1533111681
not encoded well. But not sure if it is a gateway issue.The text was updated successfully, but these errors were encountered: