ERROR 411 consuming API in java (POST METHOD)

Question

I am working on a personal project to learn how to work with Rest web services.

I have an API web application in Visual, which is my controller and where the connection to Oracle is made, and a web application in JAVA and with a JSON library, in addition to trying to do it in layers according to what I learned in the institute.

When I make the GET request, I have no problem, they bring me the data, but when I make a POST request as a customer's registrar it is when the problems start and I get the error 411 in java.

I Read looking for the solution that some worked for them by placing the "Content-Length" I don't know if I put it right but I still have the problem.

    public int insertarCliente(Cliente c){
        globalURL += "?rut=" + c.getRut() + "&nom="+ c.getNombre() +"&app=" + c.getApellidoP() + "&apm=" + c.getApellidoM();
        try {
            HttpURLConnection conn = Conectar(globalURL);
            conn.setRequestMethod("POST");
            conn.setRequestProperty("ACCEPT", "application/json");
            conn.setRequestProperty("Content-Length", "0");

            if (conn.getResponseCode() == 200) {
                //InputStreamReader in = new InputStreamReader(conn.getInputStream());
                BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream()));
                String resp = br.readLine();
                JSONObject obj = new JSONObject(resp);
                return obj.getInt("resp");
            }
        } catch (Exception e) {
            Logger.getLogger(ClienteDAO.class.getName()).log(Level.SEVERE, null, e);

        }
        return 0;
    }

The problem start in the IF.

And the error that shows me is the following:

     Glook2 was successfully deployed in 227 milliseconds.
**Grave:   java.lang.RuntimeException: Failed : HTTP Error code : 411**
    at Controllers.ClienteDAO.insertarCliente(ClienteDAO.java:50)
    at Services.cliente.registrar(cliente.java:104)
    at Services.cliente.processRequest(cliente.java:46)
    at Services.cliente.doPost(cliente.java:77)

I must emphasize that I have proven in the POSTMAN that the web services method works and correctly adds the data to the database.

String globalURL = "http://localhost:60367/api/Cliente";
    HttpURLConnection conn;

    public ClienteDAO() {
        conn = Conectar(this.globalURL);
    }

    private HttpURLConnection Conectar(String urlRest) {
        try {
             URL url;
             url = new URL(urlRest);
             return (HttpURLConnection) url.openConnection();
        } catch (Exception e) {
            Logger.getLogger(ClienteDAO.class.getName()).log(Level.SEVERE, null, e);
        }
        return null;
    }

Answer 1

Enable logging as shown here: How to enable wire logging for a java HttpURLConnection traffic?

You will then see¹ that the Content-Length header is not sent:

FINE: sun.net.www.MessageHeader@4bf558aa5 pairs:
  {POST / HTTP/1.1: null}
  {ACCEPT: application/json}
  {User-Agent: Java/13}
  {Host: localhost:8080}
  {Connection: keep-alive}

^{1: Sample log entry, wrapped for easier reading}

That is because HttpURLConnection manages that header.

To send a Content-Length: 0 header, send no output, i.e. replace:

conn.setRequestProperty("Content-length", "0");

with:

conn.setDoOutput(true);
conn.getOutputStream().close();

Logging now shows the header:

FINE: sun.net.www.MessageHeader@5fa7e7ff7 pairs:
  {POST / HTTP/1.1: null}
  {ACCEPT: application/json}
  {User-Agent: Java/13}
  {Host: localhost:8080}
  {Connection: keep-alive}
  {Content-type: application/x-www-form-urlencoded}
  {Content-Length: 0}

---

See also: JDK-6997628: HttpURLConnection strips Content-Length header on Post:

Affects Version/s: 6u22
Status:            Open
Resolution:        Unresolved

BT2:EVALUATION

The fix for CR 6961084 restricts the setting of some potentially security sensitive headers. Since these headers were allowed to be set in previous releases then of course compatibility is effected. A decision was made that compatibility was secondary to the security risk these headers posed. We understand that there may be valid apps out there that will be effected by this, so the sun.net.http.allowRestrictedHeaders property was added to revert to previous behavior.

BT2:WORK AROUND

Run with -Dsun.net.http.allowRestrictedHeaders=true

I would not recommend using that workaround.