Request mapping not executed

Question

Im not quite sure if this is related to spring or not :D

I have a form:

<form class="csvForm" method="post" action="/admin/myentity/bulkUpload" style="display: none;">

and I have a controller:

@RequestMapping("/" + AdminMyController.SECTION_KEY)
@Secured("PERMISSION_OTHER_DEFAULT")
public class AdminMyController extends AdminBasicEntityController {
    protected static final String SECTION_KEY = "myentity";

@RequestMapping(value = "/bulkUpload", method = RequestMethod.POST)
public String showBulkUpload(HttpServletRequest request, HttpServletResponse response, Model model) throws IOException {
  Map<String, Object> responseMap = new HashMap<String, Object>();

  return "sts";
  }
}

Im wondering why it wont get in showBulkUpload method :o when I changed the method into GET.. it will get in the method.. Im wondering what did I miss

and btw, there's no issue with the controller bean coz it gets scanned 100%

Answer 1

This is somewhat related to Spring but is more specific to the CsrfFilter in Broadleaf. I am going to guess that there is a stack trace in your logs from CsrfFilter. This filter (hooked up in applicationContext-security.xml in Broadleaf) will ensure that all POST requests have a csrfToken request parameter (CSRF stands for Cross Site Request Forgery). If you replace the snippet you posted:

<form class="csvForm" method="post" action="/admin/myentity/bulkUpload" style="display: none;">

With the blc:form Thymeleaf processor (which automatically populates a csrfToken hidden input parameter) into your HTML):

<blc:form class="csvForm" method="post" action="/admin/myentity/bulkUpload" style="display: none;">

Then it should work.

Answer 2

Http GET and POST methods has different characteristics. As for your case, I just guess about the name you have given, which is bulkUpload and you are trying to upload a large amount of data. Http GET capacity is limited when you compare it to POST method. So if you are trying to upload a large amount of data, then you may not be able send it through GET method, up to your browser and server.

GET method capacity may change according to client browser as well as your web server. If server cannot process, because of the length of GET method, it should raise 414 Request-URI Too Long.

The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).

Reference

10.4.15 414 Request-URI Too Long

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query
information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the Request-URI.

Reference

For client site, browser GET method capacity is as follows:

• Firefox No Limit (Reference)
• IE 2KB (Reference)
• Chrome No Limit (Reference)

It is highly probable that you use IE in your testing, if you cannot access to your Spring Controller. If you are using Chrome or Firefox, your web server might not handle GET method with that long data.

Additional info can be found in here.