berry webserver class

[storchalberto]

I am using the webserver functions to develop personal pages stored on the tasmota esp32. To do this i read in a string the page from the UFS and send it using the webserver.content_send. It function well if the string read do not contain a null character (normal for html pages). If i want to send an image file for example a gif, using the webserver.content_open(200, image/gif), the send to the browser stops when in the string is found a null character. I do not know if the problem is in the read of the file in a string or in the send. To avoid the problem there is a solution?

[sfromis]

The short version of the issue is that a text string in Berry is null-terminated, meaning that it cannot contain a null. Thus the trouble is not when you send the image, but instead when you read it into a string, which becomes invalid. You should instead read it into a bytes object (using readbytes() on the file handle), which since some time now is also valid as an argument to content_send.

An alternate strategy would be to embed the image in the page you want to send, instead of having it served separately. In the html using f'<img src="data:{mime};base64,{resp}"/>', with the mime variable being obvious, and the resp variable the outcome of filehandle.readbytes().tob64()

[storchalberto]

thanks can you tell me where to investigate?

[s-hadinger]

Looking at the doc, I feel it does auto conversion from String to Arduino Url which is exact match.
It would require to add some Berry options for glob or regex matching.

But this needs testing, because in my memory it was prefix matching.

I will out for some time, you'll need to test on your own for now.

[storchalberto]

Thanks, i do not understand how to do the testing from my berry code, i cannot modify the arduino or berry interpreter code. I will wait for you to see the solution. bye

[sfromis]

AFAICT, he meant that for now you can continue your testing without having the feature of pattern matching.

If you use the technique of embedded images (instead of served separately), that could reduce the number of http endpoints you need.

[sfromis]

Anyway, you could also have an endpoint allowing you to use a broad-scoped handler, working with URL formats like:
http://tasmotadevice/image?name=myimagefile.gif
Then the handler could pick up the "name" argument and serve the file.