The main target of this recipe is how to create a simple controller with @RequestMapping used to assign URLs to both the controller and its request handlers. Then, it is followed by topics on how to the use of RequestMethod.PUT and RequestMethod.DELETE with topics on file uploading as a PUT request transaction.

To start, the use of @RequestMapping is not limited to the @Controller level when we deal with URL mapping. The annotation @RequestMapping("/simple"), for instance, is attached on top of the @Controller declaration, which means that all the handling methods are called relative to the given path /simple. The other @RequestMapping("/upload.html") found on the method uploadFileSubmit() indicates that this request transaction is executed whenever the end of the URL matches

/upload.html or /ch03/simple/upload.html.

In the other part of the recipe, the use of HTTP methods other than GET and POST are always given in any application server, especially if the specification does not fit with GET or POST alone. Spring 5.0 supports HEAD, GET, POST, DELETE, PATCH, TRACE, and OPTIONS request methods that can be used anytime depending on the nature of the transaction. As with file uploading, the PUT transaction is always associated with file processing, such as sending and updating files to the file storage. Likewise, the PUT method can also be used in handlers that update database records. There is also the inclusion of the DELETE transaction in our controller, which may be used to focus on database record deletion or file removal from a repository. In cases like REST services, the DELETE transaction may require a URL request parameter which indicates which component will be deleted. Using the DELETE method in form handling has one problem and that is HTML forms support only GET, POST, or HEAD, which makes this <form> snippet:

<form action="${pageContext.request.contextPath}/simple/ 
      upload.html"  
  enctype="multipart/form-data" method="PUT"> 
    <input type="file"name="file"/> 
    <input type="submit" value="Submit"/> 
</form> 

This is capable of triggering HTTP Status 405:

To fix this problem, we need the Spring Form tag library to bind the <form> to the Spring framework, and an inclusion of HiddenHttpMethodFilter in our servlet container:

<form:form  modelAttribute="uploadFileForm"  
  action="/ch03/simple/upload.html" enctype="multipart/form-data" 
  method="PUT"> 
      <input type="file"name="file"/> 
      <input type="submit" value="Submit"/> 
</form:form>

The preceding resulting component, <form:form>, will give us auto-generated HTML with a _method parameter having PUT as a value:

<form id="uploadFileForm" action="/ch03/simple/upload.html" 
 method="post" enctype="multipart/form-data"> 
 <input type="hidden" name="_method" value="PUT"/> 
       <input type="file" name="file"/> 
       <input type="submit" value="Submit"/> 
</form> 

But examining the preceding code, there is only one unexpected <form> attribute that showed up, and that is the method="POST". This means that the filter HiddenHttpMethodFilter forwards the request to the DispatcherServlet as a POST transaction first before it reaches the method handler bearing the PUT method. Because of this internal filter processing, the handler method, uploadFileSubmit(), must not only map to the PUT request method type but also to POST:

@RequestMapping(value="/upload.html", 
method={RequestMethod.PUT, RequestMethod.POST}) 
public String uploadFileSubmit(Model model, 
  @ModelAttribute("fileUploadForm") FileUploadForm 
    fileUploadForm, HttpServletRequest req) { } 

Otherwise, it will give you the same HTTP Status 405 error. On the other hand, the DELETE request is forwarded as GET first to the DispatcherServlet before it reaches the controller as a DELETE transaction.

Another solution that can be useful in recognizing PUT and DELETE is to configure the CorsFilter of Apache Tomcat 9 by overriding its cors.allowed.methods property, which is a comma-separated list of HTTP methods, which, by default, only includes GET, POST, HEAD, and OPTIONS.