I am getting big files from client. I am using MultipartRequest to handle the request.
but its throwing exception
java.io.IOException: Posted content length of 3921442 exceeds limit of 1048576
I tried by adding following code(filter) in web.xml. but its not working
<filter>
<filter-name>multipartFilter</filter-name>
<filter-class>com.oreilly.servlet.MultipartFilter</filter-class>
<init-param>
<param-name>maxSize</param-name>
<param-value>5000000</param-value>
</init-param>
</filter>
Use the request constructor:
public MultipartRequest(HttpServletRequest request,
String saveDirectory,
int maxPostSize)
There you can specify the maxPostSize which is a limit of file size.
Related
In our Web app we've faced a bad encoding problem. In order to reproduce this problem user selects in browser non unicode encoding(as example in chrome -> More tools->encoding->Koi8) and tries to set Cyrillic text.
Chars were spoiled when it goes to controller (just checked on debug) and even it's stored incorrectly and incorrectly rendered.
We've followed all recommendations: http://balusc.blogspot.com/2009/05/unicode-how-to-get-characters-right.html and seems this is a problem with submitting of application/x-www-form-urlencoded encoding content type. Because it's impossible to set charset during such forms submits.
As example if submit the same data using json and set necessry content type everything is stored correctly.
We've also tried example with this article:
http://www.codejava.net/frameworks/spring/spring-mvc-form-handling-tutorial-and-example and added additionally UTF8 filer with the following method:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException,
ServletException {
request.setCharacterEncoding("UTF-8");
response.setCharacterEncoding("UTF-8");
chain.doFilter(request, response);
}
But the same problem was reproducible.
Could somebody suggest how to resolve mentioned problem?
Is it possible to correctly handle mentioned use case in Spring MVC because we tried on simple example and it seems it doesn't work. Does this use case of changing browser encoding valid at all ?
Try : In web.xml
<filter>
<filter-name>encoding-filter</filter-name>
<filter-class>
org.springframework.web.filter.CharacterEncodingFilter
</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encoding-filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Refer : http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
Also, in view if you use jstl try to set the default encoding
This behavior can be achieved by using accept-charset="UTF-8" attribute in form.
It can be added in spring form tag. Also there's a bug in older versions of struts (1.1 are affected)
https://issues.apache.org/jira/browse/STR-1636
that makes impossible to add this attribute directly to the form. As a workaround jQuery can be used
jQuery( document ).ready(function() {
jQuery("#formSelector").attr("accept-charset", "UTF-8");
});
So in a nutshell this attribute will force browser send data from this form using specified encoding. In case user will set some control characters into the input they will be sent to backend as well so validation is required to prevent such cases. Also cases where the browser encoding and keyboard languages are not working well together will be handled (for example KOI8-U and Chinese keyboard language).
accept-charset official documentation
Somewhere in your request pipeline your overriding the encoding (ie String.getBytes() or new String(bytes) is being called with out the right encoding.
There are so many places that this can potentially happen and its one of the reasons why Spring Boot and various other frameworks force UTF-8 for both input and output particularly since UTF-8 is the recommended encoding.
Your users should not be changing the encoding. In fact when the page loads both the servlet response and the HTML itself should specify UTF-8 and this is for good reason. The server is saying "I speak UTF-8". If you want a different encoding you will have to specify a different encoding in the HTML (ie jsp), and the servlet request/responses so that the browser will then auto select encoding. Even then your mileage will vary for application/x-www-form-urlencoded particularly if you use Javascript (probably because the spec on the encoding in other characters is somewhat ambiguous). To give you some more example of why the HTML has to have the exact same encoding as what your sending over is that the name value pairs will have different encoding. That is your form has UTF-8 request parameter names (because thats whats in the HTML) but when you override it your supplying a different encoding for the parameter values (ie ?UTF-8Name=KoiValue&UTF-8Name=KoiValue). Hopefully you can see why that is bad and I'm not sure chrome is smart enough (or if it even should do it) to change the request parameter names back to Koi8.
Thus if you absolutely must support other character encoding you probably should use multipart/form (you specify this in the enctype attribute on the form element) AND NOT USE the encoding filters that set UTF-8 as those will probably cause corruption.
I am facing a very general Spring message issue but so far doesn't have a simple solution, so hope everyone here can enlighten me a little bit.
Current Spring MVC application has an issue on properly display Spanish accent characters on javascript alert. The alert message now shows up like this:
Por favor elija la fecha de aplicación
but it is supposed to show up like this:
Por favor elija la fecha de aplicación
above message pops up when user failed the validation, which processed by javascript:
alert("<spring:message code='message_miss_duedate' />");
but if I put the whole string in Spanish into the javascript:
alert("Por favor elija la fecha de aplicación");
the output is fine.
Cause of the issue is obvious: the &Xacute; is generated by method from Spring message to convert Spanish accent characters to HTML friendly codes, which works fine when parsed by html, however, such code is not recognized by javascript.
So far the 'EncodingFilter' is set to UTF-8
<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
and same to the pom setting:
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
So, is there anyway to skip the accent character conversion by Spring when using Spring message? Thanks.
UPDATE
The solution is very simple, use htmlEscape="false" in spring:message, by default the value is true hence the escaping characters
so
alert('<spring:message code="message_miss_duedate" htmlEscape="false"/>');
now pop up message looks pretty.
END of UPDATE
Now I have a workaround but not a solution because it has limitation, so I will leave this thread open until there is a general solution:
In the controller using Spring MessageSource object to pass the alert message into uiModel:
Locale currentLocale = LocaleContextHolder.getLocale();
uiModel.addAttribute("message_miss_duedate", messageSource.getMessage("message_miss_duedate", null, currentLocale));
So in javascript we can get the message like normal JSTL variable
alert("${message_miss_duedate}");
But like mentioned this approach as limit because it is difficult to handle runtime responding message with variable, especially with code template.
I have a form which submit details like name, address, affiliations. Here these inputs will in different language like french, Spanish, German, Russian and so on. I point that these inputs are some time have non English keyboard character and are submitted as different character like &,^ and so on.
for example,
this is the input
Instituto de Quı´mica, Universidade de Sa˜ o Paulo, Sa˜ o Paulo,
Brazil
and this is the data that saved in DataBase while I submit the form
Instituto de Qu?´mica, Universidade de Sa˜ o Paulo, Sa˜ o Paulo, Brazil
I have set the character set as UTF-8 in database and in jsp page first later I found that struts 2 form has a tag attribute acceptcharset="UTF-8"
and it has been working for only few other language but not for Spanish, Portuguese nad many more.
so what is the solution for this issue?
I have Fix this by changing UTF-8 in pageEncoding and charset in HTML page where ever I see this and in form i used acceptcharset="UTF-8" and last I get issue in storing it in DB even its charset is charset is UTF-8 so I forced DB connection to use UTF-8 by providing jdbc:mysql://localhost:3306/yourDB?useUnicode=true&characterEncoding=utf8 in connection url
You can use Spring filter, and force the encoding to UTF8.
Add this to your web.xml:
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
If you need to force jsp to UTF-8 you can write the following in web.xml:
<jsp-config>
<jsp-property-group >
<url-pattern>*.jsp</url-pattern>
<page-encoding>UTF-8</page-encoding>
</jsp-property-group>
</jsp-config>
I am confused about the way the DefaultAnnotationHandlerMapping works.
In my web.xml I have
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>/somePath/someWork</url-pattern>
<url-pattern>/users</url-pattern>
<url-pattern>/user/*</url-pattern>
</servlet-mapping>
I have the controller like this,
#RequestMapping(value="/user/adduser", method={RequestMethod.POST})
public void addAdmin(#ModelAttribute("myData") myData data) {
System.out.println("We reached adduser controller");
}
And in the jsp file i have
<form:form id="adduser" method="post" action="/user/adduser" commandName="myData">
This does not work. I get the error no handler mapping found for "/adduser" and 404 for the page "/user/adduser"
But in the .xml file if i mention
<url-pattern>/user/adduser</url-pattern>
it works, or if i make the controller like,
#RequestMapping(value="/adduser", method={RequestMethod.POST})
also works. When submitting the page it reaches the correct controller.
I am now confused the way the #ReuqestMapping works. When a request comes like "/user/adduser" from where it will start looking for the right class and the right method?
Spring will match against the pathInfo property of the HttpServletRequest.
If your web.xml specifies <url-pattern>/user/*</url-pattern>, then the pathInfo will be the path with the /user prefix removed, so the #RequestMapping has to be /adduser.
If web.xml specifies <url-pattern>/user/adduser</url-pattern>, then the pathInfo will be the full /user/adduser path, so #RequestMapping has to match against that.
This isn't done by Spring, but by the servlet container, and it can be a bit confusing at times.
You can mitigate against this by using wildcards in #RequestMapping, e.g.
#RequestMapping(value="**/adduser", method={RequestMethod.POST})
when I submit the character Ö from a webpage the backend recieves Ã. The webpage is part of a Spring Webflow/JSF1.2/Facelets application. When I inspect the POST with firebug I see:
Content-Type: application/x-www-form-urlencoded
Content-Length: 74
rapport=krediet_aanvragen&fw1=0&fw2=%C3%96ZTEKIN&fw3=0&fw4=0&zoeken=Zoeken
The character Ö is encoded as %C3%96, using this table I can see that it is the correct hexadecimal representation of the UTF-8/Unicode character Ö.
However when it reaches the backend the character is changed into Ã. Using the same table I can see there is some code somewhere that tries to interpret the C3 and the 96 separately (or as unicode \u notation). U+00C3 happens to be Ã, 96 is not a visible character so that explains that.
Now I know this is a typical case of an encoding mismatch, I just don't know where to look to fix this.
The webpage contains
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
When debugging I can see the library responsible for the wrong interpration is jboss-el 2.0.0.GA, which seems right because the value is parsed to the backend in a webflow expression:
<evaluate expression="rapportCriteria.addParameter('fw2', flowScope.fw2)" />
It is put onto the flowScope by:
<evaluate expression="requestParameters.fw2" result="flowScope.fw2"/>
Nevermind the convulated way of getting the form input into the backend, this is code that tries to integrate Webflow with BIRT reports...but I have the same sympton in other webapplications.
Any idea where I have to start looking?
I can see that it is the correct hexadecimal representation of the UTF-8/Unicode character Ö. However when it reaches the backend the character is changed into Ã.
So the client side character encoding to encode the POST body is correct, but the server side character encoding to decode the POST body not. You need to create a Filter which does basically the following in doFilter() method
request.setCharacterEncoding("UTF-8");
and map it on URL pattern of interest. Spring also already provides one out the box, the CharacterEncodingFilter which does basically the above. All you need to do is to add it to the web.xml:
<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>characterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
See also:
Unicode - How to get characters right? - JSP/Servlet requests - POST
The HTML meta header is by the way irrelevant in the issue, it's ignored when the page is served over HTTP. It's the HTTP response header which instructs the webbrowser in what charset it should display the response and to send the params back to the server. This is apparently already been set properly since the POST body is correctly encoded. The HTML meta header is only been used when the user saves the page to local disk and revisits it later from local disk.