The web container itself proactively urldecode the parameters of the HTTP request

This article is reproduced from: the Web container itself actively to the HTTP request UrlDecode processing

Title. Perhaps a lot of people in Java have not noticed that when we send an HTTP request, assuming that the accompanying reference is UrlEncode, after reaching the Web container, the developer gets the number of participants to become the value before encode. This is a very good feature, and developers can completely ignore whether the HTTP parameters need to decode such a thing, but what happened to decode?

The first step is to start with the Request.getparameter () method, but ServletRequest is just an interface, which is a basic interface of the servlet framework defined by the Java EE, and the detailed implementation of the servlet container. That is, the Web container. I'm using JBoss. So start with the source code from JBoss.

At the same time in order to find out when we call Request.getparameter () in detail is the method of calling which ServletRequest object, using reflection to find. The code is as follows:

System.out.println(request.getClass().getName());  

Very easy, get the detailed name of the object through request GetClass, the result is: Org.apache.catalina.connector.RequestFacade. It is visible that the Web container provides a detailed ServletRequest implementation class, now that you have found the detailed class, you must look at the API documentation to see if there is any mention of the decode operation for the request reference value. By the way, Org.apache.catalina.connector.RequestFacade when the Tomcat API, sure enough the document did not mention whatever about decode content, but see Requestfacade is just a wrapper, really work actually another person, Okay, just find the code.

Find the source code for the Requestfacade and discover that the class that is really used to get the request reference is a protected variable request for Requestfacade, and of course this class implements the ServletRequest interface. Continue to review the request source code and find out if the actual class is not it, Request internal Another variable org.apache.coyote.Request.coyoteRequest, continue to find Org.apache.coyote.Request source code. Finding the Org.apache.coyote.Request source code roughly shows exactly when the decode operation was performed. In the Org.apache.coyote.Request constructor, you can see:

public  request  () {this . Parameters.setquery (this . querymb); this . Parameters.seturldecoder (this .    Urldecoder);    this . Parameters.setheaders (this . Headers);    this . Methodmb.setstring ( "GET" );    this . Urimb.setstring ();    this . Querymb.setstring ();  this . Protomb.setstring (); }

One of the This.parameters.setURLDecoder (This.urldecoder), specifies the Urldecoder tool class, and then see parameters can see that the class is used to resolve the HTTP request parameters of the class, The class uses the Urldecoder tool class to perform decode operations on the requested name and value. Basically, we have seen how the parameters in the HTTP request are actively decode.

It doesn't go into the code step, after all, we just need to know what's going on decode.

It can be seen from the whole process above. It is not the Java standard that the Web container relies on its own active decode for HTTP parameters. So it is possible that other web containers do not do so, so developers have to pay attention.

The web container itself proactively urldecode the parameters of the HTTP request