We Keep Coding

URL truncated when it contains semicolons

I'm running a Java Spring application on Tomcat that accepts HTTP requests from a web browser. My URL requests are of the form http://some_server/search/id/123;456
The javascript library function encodeURIComponent is used to encode any special characters from the URL before sending it to the application
e.g. http://some_server/search/id/123%3B456
However, remote debugging the application reveals that the URL request is truncated at the semicolon. I.e. the URL only contains characters before the semicolon like so: http://some_server/search/id/123
Debugging beakpoint was at the entry point in the controller where Spring MVC provides the HttpServletRequest.
Many thanks for any assistance provided.

You should use pattern in #RequestMapping like this
#RequestMapping(value = "/search/id/{id:^[0-9;]+$}")
public String test(#PathVariable(value = "id") String id) {}

Spring Rest Request 406 Not Acceptable for ".123"

I have a Spring RestController with a RequestMapping and a PathVariable:
#RequestMapping(value = "/path/{someId:.+}")
public void method(#PathVariable("someId") String someId) {
...
}
When calling this controller, I get a Http 406 Not Acceptable error with requests like:
- /path/id8327.123
- /path/id8327.txt
But not with:
- /path/id8327.234
- /path/id8327.bbb
Isn't that strange?
It was only recently I found out that .txt also failed, so I guess it has something to do with extension mappings.
How can I work around this hidden feature?
Kind regards

You can add a '/' at end of the URL, like:/path/id8327.123/.
This method can help Spring to recognize.

I ran into this issue while calling an endpoint that had an IP #PathVariable at the end.
Apparently, there is an older MediaType: application/vnd.lotus-1-2-3.
Spring tries to determine what the MediaType to return should be and it does this first by finding a possible MediaType extension in the URL.
In this case it finds the extension as the String after the last '.'
For the '123' case Spring thinks that the MediaType should be the value for the MediaType map key '123' which is 'application/vnd.lotus-1-2-3'.
The easy fix is to change #PathVariable into #RequestParam and pass the value as an URL query parameter.

Spring Boot #RequestParam truncating URL's passed in with ?'s and #'s

I've seen a similar issue to this when using Spring MVC #PathValue but none of the solutions online for that worked for this issue.
I am currently working on an app where users will enter a URL and #RequestParam seems to truncate the URL's passed in on ?'s and #'s.
#RequestMapping(value = "/route/path", method = RequestMethod.GET, produces = "application/json")
public Value method(#RequestParam(value="url") String url, HttpServletRequest request) throws Exception {
//execute code
Now for example if someone were to pass in localhost:8080/route/path?url=https://css-tricks.com/hash-tag-links-padding/#article-header-id-0
the query would be truncated to url=https://css-tricks.com/hash-tag-links-padding/
The same thing seems to happen with '&' as well. I've tried a myriad of solutions around regexes, Bean configuration, and overriding configurePathMatch in WebMvcConfigurerAdapter.
Has anyone else had this issue? If so, did you find a work around? Thanks in adavance!

Use encodeURIComponent to encode your parameter url.

You need to use Percent Encoding on the incoming url.
# is %23
? is %3F

Dynamic URL special characters : #PathVariable

I am using Spring and Hibernate in my project.
Is there a way to handle dynamic URL(i.e. hyperlink which is populated dynamically depending on searchResult) through modelAttribute i.e. using a variable and passing same to controller just like passing input bean??
I am using #PathVariable for handling dynamic URL action from JSP to Controller. During the same if my dynamic URL contains combination of special characters like ./ then the URL is getting truncated.
Please help.

Possibly you may be experiencing a similar problem with Spring MVC Getting PathVariables containing dots and slashes.
Where it was resolved by changing the url declaration where its attribute instead of /{attribute} added the value in the url as/{atributo:.+}

Why is my Spring service returning any content type requested by client?

I have a Spring rest service using Spring 3.1.0.RELEASE. Here is the relevant code for the service call in question:
#RequestMapping(value="/{var1}", method=RequestMethod.GET, produces="application/json")
#ResponseBody
public String getSomeStuff(#PathVariable final String var1) {
return myJsonString;
}
If I call this using the following curl command, it happily returns me my json string with a content-type of application/xml whereas I would expect a 406 based on the Spring 3.1 docs:
curl -v -H "Accept: application/xml" http://localhost:8080/MyServiceSite/myvalue
There is no extra configuration in my app for this service (no serialization), I am returning raw json with no post-processing for the service configured. I'm certain I have missed something, can anyone point out anything I may have missed?
Edit: Here is the documentation I was looking at when attempting to get this working. Specifically section 16.3.2.5. My code is very similar except that their code looks like it assumes config setup to let Spring handle serialization. Perhaps the produces does not work when bypassing the Spring serialization?
Edit: I changed my expectation for the response code. A 415 would indicate I was sending improper content in my request body whereas 406 is proper for having an accept header that doesn't jive with the content type of the server.
Anyway, I have changed this method do return a Map and added config for it to serialize to json and now if I send an invalid content type from the client I get the proper 406 response. It seems that maybe the "produces" setting is ignored when the output of the method is not being serialized.

The produces condition is new to Spring MVC 3.1 and is only supported with the RequestMappingHandlerMapping and related #MVC support classes, also new in Spring 3.1. My guess is that you're using the 3.0 #MVC support classes, which do not support the produces condition. Your code otherwise is correct and so are your expectations of what should happen.
The use of headers="Accept=application/json" is unnecessary in 3.1. That's exactly what the produces condition was introduced for.

What about the headers attribute for the #RequestMapping. You could set the Accept header in there. Something like:
#RequestMapping(value="/{var1}", method=RequestMethod.GET, produces="application/json", headers = "Accept=application/json")
#ResponseBody
public String getSomeStuff(#PathVariable final String var1) {
return myJsonString;
}
I don't know how Spring would handle a request to that path without a matching header. If it doesn't give what you want you might need to define a similar mapping without the headers and have it send back a ResponseEntity and set the response code or something, but I would hope it would handle it appropriately.