pierregrenoble:
The server returns without any problem information to
the browser (here we just return
TOTO </ h1>) but …
the HTML code is never interpreted by the browser !!
You are sending HTML headers as part of your response. It looks like you are using BridgeServer/BridgeClient in the same manner as one would use WiFiServer/WiFiClient, and I think that is your problem.
BridgeServer/BridgeClient works very differently from WiFiServer/WiFiClient:
- WiFiServer/WiFiClient implement a simple network socket. When a request comes in, the WiFiClient receives all of the request headers and the body of the request. In response, the code sends the response headers and response body back through the WiFiClient. This is done because the WiFi Library is talking to a basic network interface that can handle TCP streams, but knows nothing of the HTTP protocol that is riding on top of that stream, therefore the code must handle all of those details.
- BridgeServer/BridgeClient, on the other hand, handles all of the HTTP protocol details internally. This is because the BridgeClient object is talking to an intelligent process on the Linux side of the Yun. In this case, the Linux side is managing the HTTP protocol, passing only the last part of the URL to the BridgeClient, and expecting only the body of the response in reply.
The intent of the WiFiServer/WiFiClient is to provide a raw TCP socket and the sketch handles the HTTP details. The intent of the BridgeServer/BridgeClient is to easily implement a REST API as demonstrated in the Bridge example. When you make an HTTP request to /arduino/ the Linux side accepts the request, processes the headers, and reads the requested URL. It sees the /arduino/ part of the URL and knows that you want to talk to a BridgeClient in the sketch. It extracts the remaining part of the URL (the part) and passes that to the sketch over the serial port. The sketch can then read the remaining part of the requested URL from the Client object, and write the body of the response. The Linux code then takes the provided body of the response, and wraps it up in an HTTP response by adding its own headers.
Running your code, and looking at the actual response from the Yun, I see:
[color=red]HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
Cache-Control: no-cache
Expires: 0
[/color]
[color=blue]HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Connection: close[/color]
[color=green]<!DOCTYPE html>
<html>
<head><title>Arduino YUN</title></head>
<body><h1>TOTO</h1></body></html>[/color]
The red text contains the headers that were automatically added by the Linux side, the blue text contains the headers that your sketch added, and the green text contains what you intended to be the body of the response. However, the Linux side added its own headers (the red text) including the trailing blank line that shows the end of the headers, therefore everything after the first blank line is treated as the body of the response by the browser. That means that as far as the browser is concerned, the header is the red text and the content type is plain text, so the body of the response (the blue and green text) is displayed as raw text and not processed as HTML.
On the Yun, the Linux side give you a lot more processing power than has been available with the standard ways of adding networking to an Arduino. It requires a different way of thinking. The most efficient way of handling a web server is to implement it on the Linux side. A somewhat simpler way is to take a look at the Temperature Web Panel example - in this case, the Linux side serves up static web pages, and uses the BridgeClient as an AJAX API to retrieve the dynamic content of the page. Note that it’s not explicitly stated on that tutorial page, but you must load the sketch onto your Yun using a network interface, not a USB serial port, in order for the requried web page files to be copied to the Yun.
Personally, I just use the Bottle framework to implement a web server on the Linux side in Python, and let the more powerful Linux processor do the heavy lifting. The sketch just does peripheral I/O and the meat of the processing is on the Linux side.
mpeg2tom:
I’m having the same problem.
I think you have a different problem. But it may be similar in that you are likely using the BridgeClient in a manner which it was not intended.
My understanding is that port 5555 is an internal port used for communications between the sketch and the Linux side. The Linux side receives an HTTP request on port 80, sees that the requested URL starts with /arduino/, so it it makes a connection to port 5555, which gets rerouted over the serial port to the BridgeClient running as part of the sketch.
The Linux side may be listening on port 5555, but it’s listening for a local connection from the sketch, not for a connection from an outside computer. Therefore, the connection attempt is reset.