TM4C129XNCZAD: Issue with HTTP server with port number 8000

Hi,

 I'm currently out of office. I will look back to your problem tomorrow. Sorry for the delayed response.

Hi,

  I'm not an expert with the HTTP and neither NDK.  Official HTTP port should be 80. Why would you want to use 8000 instead of 80? See https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#References_and_notes

 Can you look at this post which maybe helpful. 

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/691279/rtos-ti-rtos-http-server-post-file-example

 Please also take a look the HTTP server example provided by Todd. 

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/947315/faq-tm4c1294kcpdt-do-you-have-an-example-of-a-http-server-on-a-tivac-device-running-ti-rtos-sys-bios

Thank you, Charles, for your answer.

After thoroughly checking all XDC configurations and reviewing my code, I haven't been able to determine the exact cause of the problem. However, I did make some progress. I had a functional HTML and JavaScript sample code that worked on both ports 80 and 8089, following the same principles and using web sockets.

When I replaced the sample code with my original HTML and JavaScript files, I encountered an issue where the code worked correctly on port 80. The CGI successfully received and responded to the data. However, when testing with Chrome and Postman, I received the following error: net::ERR_INVALID_HTTP_RESPONSE.

To investigate further, I used Wireshark to analyze the TCP messages on the Ethernet. I observed that the requests sent and the responses received were exactly the same.

Despite these efforts, I haven't been able to identify the specific cause of the net::ERR_INVALID_HTTP_RESPONSE error. I have checked the XDC configurations, reviewed the code, and analyzed the network traffic. At this point but still can't figure out the cause.

the board also responded correctly on the network to port 8080 as it did with port 80 but the client terminates the connection and issued this error  net::ERR_INVALID_HTTP_RESPONSE  even though the data exists or that is what I see on the ethernet connection using Wireshark also I tried to add connection rules that allow incoming and outgoing connections on the port 8080 so if the firewall blocking it or something but the issue persists.

Hi Hazem,

  I don't know what is causing the problem. 

hazem khaled said:

I had a functional HTML and JavaScript sample code that worked on both ports 80 and 8089, following the same principles and using web sockets.

I assume you have run this functional HTML and JS sample code on the MCU, correct? Or this is run on a different platform?

hazem khaled said:

When I replaced the sample code with my original HTML and JavaScript files, I encountered an issue where the code worked correctly on port 80.

What is the exact difference between the functional sample code and your original HTML and JS?

hazem khaled said:

However, when testing with Chrome and Postman, I received the following error: net::ERR_INVALID_HTTP_RESPONSE.

To investigate further, I used Wireshark to analyze the TCP messages on the Ethernet. I observed that the requests sent and the responses received were exactly the same.

First, the ERR_INVALID_HTTP_RESPONSE is an issue caused by the response from the client to the server, correct?

Can you compare the requests and responses in more detail by comparing the packets byte by byte. Are they exactly the same between the sample code and your own code?

hazem khaled said:

the board also responded correctly on the network to port 8080 as it did with port 80 but the client terminates the connection and issued this error  net::ERR_INVALID_HTTP_RESPONSE

Can you clarify one more time, is this error message what you see on the PC browser for the client side? Or this is what you see on the CCS console when the client fails to respond? 

Have you tried different network such as your home network? I wonder if it makes a difference on a different network. If you have a switch, you can configure the switch to do a port forwarding so that Wireshark can capture everything that is sent/received to the MCU. 

the html and js codes are on the MCU and requested correctly except for the CGI request that I make from the Chrome console as follows

fetch("http://10.1.0.204:8080/Web_u8WebServerCGI.cgi", {
  method: "POST",
  headers: {
    "Content-Type": "text/plain;charset=UTF-8",
    "Authorization": "Basic YWRtaW46YWRtaW4="
  },
  body: "Mode=1,CMD=18,0,"
})
  .then(response => {
    if (response.ok) {
      console.log("Ready");
      return response.text();
    } else {
      console.log("Error");
    }
  })
  .then(data => {
    console.log(data);
  })
  .catch(error => {
    console.log("Error:", error);
  });

static INT8U Web_u8WebServerCGI(void *pvCGISocketData, INT32S s32RXMsgLength)
{
    vValidateCGISocketInfo(pvCGISocketData, &objstrWebSocketInfo);
    httpSendClientStr(pvCGISocketData, "[[32],[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99],[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],[[39,\"F\"]],[[60,\"Board Settings\",0,0,\"(111)\",\"sb18\",0,0,1],[0,0,5,\"b1\",\"Serial Number\",1,0,1,21285772,5,\"b2\",\"Firmware Version\",1,1,1,\"02.00.af.00.00.00.00\",5,\"b3\",\"MAC Address\",1,1,1,\"c4-7c-8d-00-0d-1e\",5,\"b4\",\"Downloading XML Version\",1,1,1,\"9.4.21.2.2.1\",5,\"b5\",\"Protocol Number\",1,1,1,\"6.11.20.9.17.2\",5,\"b6\",\"Configuration Version\",1,1,1,3]]]");
    
    return (1);
}

POST /Web_u8WebServerCGI.cgi HTTP/1.1Host: 10.1.0.204:8080
Connection: keep-alive
Content-Length: 16
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Origin: http://10.1.0.204:8080
Referer: http://10.1.0.204:8080/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,ar;q=0.8
Mode=1,CMD=18,0,[[32],[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99],[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],[[39,"F"]],[[60,"Board Settings",0,0,"(null)","sb18",0,0,1],[0,0,5,"b1","Serial Number",1,0,1,21285772,5,"b2","Firmware Version",1,1,1,"02.00.af.00.00.00.00",5,"b3","MAC Address",1,1,1,"c4-7c-8d-00-0d-1e",5,"b4","Downloading XML Version",1,1,1,"9.4.21.2.2.1",5,"b5","Protocol Number",1,1,1,"6.11.20.9.17.2",5,"b6","Configuration Version",1,1,1,3]]]

they are the same and on the TCP requests level I think they would be different as there are many TCP packets sent to terminate the connection which I copied earlier in previous comments with the [RST] tag

also, I tried other networks, directly connect the Ethernet of the MCU to PC, and used my home router also used wireshark with such filter ip.src== 10.1.0.204 || ip.dst==10.1.0.204

to find out requests coming to and from the MCU with this IP 10.1.0.204 

Hi, 

  I'm still not sure what is the problem. However, I simply do a beyond compare diff between the two REDS and the two BLUES. The two BLUES are identical. But there is a subtle difference between the two REDS. See below. If you look at the first line for 8080 port, the POST command and the Host are concatenated into the same line. I will suggest you break it into two lines just like what you have for port 80 and see if that makes a difference. 

they are the same even the two REDS except for the port number but with the logs I sent earlier there is a timing issue with different ports than port 80 for HTTP requests the behavior is that the MCU continues sending packets of data (a response which is the BLUE text) even the client sends TCP packet with tag [RST] which terminates the connection and the MCU doesn't listen to that command and continue sending data 

- the first thing is that I don't know why the client fires the command [RST] with port 8080 before all data packets are sent and don't with port 80 even though all settings for my PC allow connections on port 8080 (I added a rule to allow connections on this port from windows firewall settings incoming and outgoing connections)

that's why I see the same request and response on both ports 80 and 8080 but the application layer (my client (chrome console, js code that sends the request) ) detects that command of [RST] that terminates the connection before receiving all data on TCP packets Level with port 8080 

which triggers a corruption in the request itself and fires the error net::ERR_INVALID_HTTP_RESPONSE on the Chrome console

and with port 80 this TCP packet of [RST] is sent after all TCP data packets are sent and terminates the connection correctly which will work fine with port 80

the second thing is why the MCU doesn't terminate the connection upon reception of this [RST] packet and continues sending data even though the client is requesting to terminate.

Hi,

hazem khaled said:

even the client sends TCP packet with tag [RST] which terminates the connection and the MCU doesn't listen to that command and continue sending data 

  I don't know why the client is sending a RST instead of FIN to terminate a connection. RST is more like a immediate abort rather than a graceful connection close as in FIN. This article will help to understand the basics between RST and FIN. 

https://www.baeldung.com/cs/tcp-fin-vs-rst#:~:text=An%20RST%20message%20aborts%20a%20TCP%20connection.&text=In%20practice%2C%20an%20RST%20message,from%20the%20other%20entity%20communicating.

hazem khaled said:

the second thing is why the MCU doesn't terminate the connection upon reception of this [RST] packet and continues sending data even though the client is requesting to terminate.

Here is another discussion that talks about using SO_LINGER with timeout of 0 that immediately close the connection. Try with SO_LINGER and see if that makes a difference. 

https://stackoverflow.com/questions/3757289/when-is-tcp-option-so-linger-0-required

I think this article also helps why RST is being sent. 

https://iponwire.com/tcp-reset-rst-reasons/