Compiler/F28M35M52C: enet_uip and enet_lwip examples does not work in Safari

Hi Dionisio,

I don't have a Mac machine at the moment to recreate the issue, so I'm going to need more information to be able to help you.

1. Please confirm if my understanding as follows is correct:

The webpage gets rendered correctly on safari (just like on chrome). And the problem only occurs when you click on a button (to toggle led or send data).

2. Do you see the same issue while using "enet_lwip" project? Or is it specific to "enet_uip" ?

3. How did you arrive at the conclusion that data/command doesn't reach concerto device?

4. What is the command sent from safari for which you observe a "mismatch in content length"?

Regards,

Sudhakar Singh

Hello
Below I reply your questions:

1. Please confirm if my understanding as follows is correct:

The web page gets rendered correctly on safari (just like on chrome). And the problem only occurs when you click on a button (to toggle led or send data).

Yes, the web page is loaded correctly into Safari. However, the buttons don't work.
In further developments of this web page I've checked that the buttons work inside the web page i.e. they can change things within the page as long as it is not necessary to send any message to the M3.

2. Do you see the same issue while using "enet_lwip" project? Or is it specific to "enet_uip" ?

The problem is in the web page provided with enet-uip. I tried to use it with enet_lwip and I got the same result.

3. How did you arrive at the conclusion that data/command doesn't reach concerto device?

Watching the "Expresion" window in Code Composer I checked out that the messages don't arrive at the M3.

I have several variables and they don't update when I push a button using Safari but they do when I use a PC with any browser.

4. What is the command sent from safari for which you observe a "mismatch in content length"?
the command is:
http.open(\"GET\", \"cmd?=\" + input + v1.value + \"&id\" + Math.random(), true);
I also tried:
http.open('GET', 'cmd?=' + 'C1' + '&id' + Math.random(), true);


Indeed, in my opinion, the problem is within these lines:
"if(window.XMLHttpRequest)"
"{"
"http = new XMLHttpRequest();"
"}"
"else if(window.ActiveXObject)"
"{"
"http = new ActiveXObject(\"Microsoft.XMLHTTP\");"
"}"
"if(http)"
"{"
"http.open(\"GET\", \"cmd?=\" + input + v1.value + \"&id\" + Math.random(), true);"
"http.onreadystatechange = Rcv;"
"http.send(null);"
"}"

Either the XMLHttpRequest object is not supported by Safari or something is wrong in the http.open fields or http.send(null) does not not work in Safari (either in any Apple device).

Thank you
Dionisio

Hi

I was wrong: the M3 receives the message sent by the web page loaded in SAFARI.

I have stored the received message in an array to watch it and this is the result: (see figure below).

However, SAFARI doesn't receives the text messages sent by uIP or lwIP so the problem seems to be in the C code used to send the message or in the code:

    "if(http.readyState == 4)"
    "{"
    "if(http.status == 200)"
    "{"
    "resp = http.responseText;"

belonging to the web page.

Dionisio

Today I can say, for sure, that the problem comes from the fact that, using SAFARI, the line http.status=200 is never reached.

Using for example Firefox and the code:

"http.onreadystatechange = Rcv;"

....

   "if(http.readyState == 4)"

   "{"

   "if(http.status == 200)"

   "{"

   "resp = http.responseText;"

   “alert(resp);”

the text sent by the M3 is correctly obtained in the resulting text box.

However, in SAFARI, (overriding the code line "if(http.status == 200)" since it is never reached):

"http.onreadystatechange = Rcv;"

...

   "if(http.readyState == 4)"

   "{"

   "if(http.status == 200)"

   "{"

   "resp = http.responseText;"

   “alert(resp);”

only a blank array is obtained in the text box.

Since Status code = 200 occurs when a file or resource is accessed via HTTP without any problem and code 200 specifically means that a URL/URI points to a tangible resource which has been successfully loaded and passed to the computer, therefore, apparently, either the packet is badly created by uip_send in microIP and send_data() in lwIP,  or is not correctly read by SAFARI.

Dionisio