Author Topic: What actual data is used to return a favicon to the browser? (Read 4539 times)

peter-h · « **on:** July 04, 2022, 07:50:27 pm »

Currently I have a simple HTTP server. All in C, no php etc. This works, serving a simple "system status" page. The page is generated with

Code: [Select]

static const unsigned char PAGE_START[] =
"HTTP/1.1 200 OK\r\n"
"Server: xxxxxx\r\n"
"Content-type: text/html\r\n\r\n"
"<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\">"
"<html>"
"<head>"
"  <title>xxxxxx Status</title>"
"  <meta http-equiv=Content-Type content=\"text/html; charset=utf-8\">"
"  <meta http-equiv=refresh content=1>"
"</head>"
"<body>"
"<pre><font size=\"+2\"><b>xxxxxx Status</font></b><br><br>";

and this is followed by the textual data of the page, and then this

"</p></body></html>\n"

How I am trying to return a favicon. This is because if I don't do this, the browser (Chrome) keeps requesting it all the time, so every time the page is hit, it gets two hits. If I returned the favicon, that should get cached.

The code I am using now is

<link rel=\"shortcut icon\" type=\"image/ico\" href=\"/favicon.ico\"/>

followed by the actual binary data of the favicon 16x16 file (generated with https://lvgl.io/tools/imageconverter)

Code: [Select]

static const unsigned char FAVICON[] = {
		  0xfb, 0xfb, 0xfb, 0xff, 	/*Color of index 0*/
		  0x6f, 0x6f, 0x6f, 0xff, 	/*Color of index 1*/

		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x2a, 0x80, 0xaa, 0xa0, 0x00,
		  0x00, 0x7f, 0xc0, 0xff, 0xf0, 0x00,
		  0x00, 0xff, 0xe1, 0xff, 0xf8, 0x00,
		  0x00, 0x7f, 0xc0, 0xff, 0xf0, 0x00,
		  0x00, 0x3f, 0x80, 0x7f, 0xa0, 0x00,
		  0x00, 0x1f, 0x00, 0x3e, 0x00, 0x00,
		  0x00, 0x1f, 0x00, 0xbc, 0x00, 0x00,
		  0x00, 0x0f, 0x00, 0xf4, 0x00, 0x00,
		  0x00, 0x1e, 0x01, 0xf0, 0x00, 0x00,
		  0x00, 0x0f, 0x02, 0xe0, 0x00, 0x00,
		  0x00, 0x1e, 0x07, 0xc0, 0x00, 0x00,
		  0x00, 0x0f, 0x0f, 0x00, 0x00, 0x00,
		  0x00, 0x1f, 0x2f, 0x80, 0x00, 0x00,
		  0x00, 0x0f, 0x3c, 0x00, 0x00, 0x00,
		  0x00, 0x1f, 0x7a, 0x00, 0x00, 0x00,
		  0x00, 0x0f, 0xfd, 0x00, 0x00, 0x00,
		  0x00, 0x1f, 0xff, 0x00, 0x00, 0x00,
		  0x00, 0x0f, 0xcf, 0x80, 0x00, 0x00,
		  0x00, 0x1f, 0xe7, 0x40, 0x00, 0x00,
		  0x00, 0x0f, 0x83, 0xe0, 0x00, 0x00,
		  0x00, 0x1f, 0x00, 0xf0, 0x00, 0x00,
		  0x00, 0x0f, 0x01, 0xf4, 0x00, 0x00,
		  0x00, 0x1e, 0x00, 0x3c, 0x00, 0x00,
		  0x00, 0x0f, 0x00, 0x3e, 0x00, 0x00,
		  0x00, 0x1e, 0x00, 0x1d, 0x00, 0x00,
		  0x00, 0x0f, 0x00, 0x0f, 0x80, 0x00,
		  0x00, 0x1f, 0x00, 0x07, 0xc0, 0x00,
		  0x00, 0x3f, 0x80, 0x07, 0xe0, 0x00,
		  0x00, 0x7f, 0xc0, 0x07, 0xf0, 0x00,
		  0x00, 0xff, 0xe0, 0x03, 0xf8, 0x00,
		  0x00, 0x7f, 0xc0, 0x03, 0xf0, 0x00,
		  0x00, 0x2a, 0x80, 0x01, 0x50, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		};

But this isn't working. Chrome (debug console) says

I wondered if

- the image is supposed to be in base64
- a more full header is required (like the one for the working page)
- some data at the end is required to close the page

Any help much appreciated.

I did find that (stackexchange tip) adding

<link rel="icon" href="data:,">

to the top header suppresses the favicon request (works with chrome, edge and firefox) but Ideally I would still like to get the favicon to work.

ataradov · « **Reply #1 on:** July 04, 2022, 08:55:47 pm »

The most recent recommended way to specify the icon is this

Code: [Select]

<link rel="icon" type="image/x-icon" href="/favicon.ico"> But yours should be good enough, browsers are really tolerant here.

The file should be just raw data with no encoding or additional headers.

You can test it by entering "http://192.168.3.73:81/favicon.ico" in the address bar, your icon should be displayed on the page. If that does not happen, then favicon won't work no matter how you specify it,

peter-h · « **Reply #2 on:** July 04, 2022, 09:25:07 pm »

Is the data the above HTML, with the last character being > and that followed simply by the binary of the favicon, and then nothing more?

The client browser must in that case be counting bytes as they arrive so it knows the end of the data.

Also that means a CRLF instead of LF or nothing, will make a difference, because it will be taken as the start of the file.

ataradov · « **Reply #3 on:** July 04, 2022, 10:12:40 pm »

There is no HTML, you just send raw data of the icon.

To clarify, there is still HTTP response, which has content type and content length fields.

Whales · « **Reply #4 on:** July 04, 2022, 10:25:41 pm »

Are you remembering to send the HTTP header before the favicon?

Request and reply 1:

Quote

------ request from browser ------
GET /

------- reply from HTTP server -------
HTTP/1.1 200 OKmydude
Content-type: text/html

<html><marquee>Burgers</marquee></html>

Request and reply 2:

Quote

------ request from browser ------
GET /favicon.ico

------- reply from HTTP server -------
HTTP/1.1 200 OKmydude
Content-type: image/x-icon

*binary data of icon goes here*

Whales · « **Reply #5 on:** July 04, 2022, 10:29:12 pm »

Also worth mentioning:

1. Use Wireshark to log the packets, that way you can see exactly what's happening.

2. Test in two different browser engines. Firefox (in my experience) is more lenient about bad HTTP headers than Chromium. Eg I think I recall Firefox accepting some forms of redirect without a proper HTTP header? It's been a year or so since I last looked. This caused a cgi app (cgi-fpm?) to fail only on Chrome and only when performing a certain action.

T3sl4co1l · « **Reply #6 on:** July 04, 2022, 11:05:09 pm »

It's any other file download; respect HTTP headers in whatever way that would be.

File format must be a compatible image. .ico is Windows Bitmap format (among others, I think?!). Like, mine is... let me see... oh heh this doesn't even open in my usual tools, what did I use, GIMP? Ah, there we go... oh weird, it was 16x19? Never noticed any weird rendering with that, but... wonder how I screwed that up so many years ago?!...

Oh right, it's, well, not precisely a BMP, anyway. Here's the hex:

Code: [Select]

0000000 0000 0001 0001 1010 0000 0001 0008 0568
0000010 0000 0016 0000 0028 0000 0010 0000 0020
0000020 0000 0001 0008 0000 0000 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0000
0000040 0000 0808 0008 0909 0009 0a0a 000a 0d0d
0000050 000d 1313 0013 1616 0016 1919 0019 1d1d
0000060 001d 2727 0027 2a2a 002a 3e3e 003e 4040
0000070 0040 4646 0046 6505 0004 4b4b 004b 5050
0000080 0050 5c5c 005c 6464 0064 9a02 0002 7272
0000090 0072 af00 0000 7f7f 007f 8d95 0085 b81e
00000a0 001e af3f 003f b82f 002a bb2a 002a bd32
00000b0 0032 c037 0037 ac73 006e ae78 006b 9d9e
00000c0 009d a5a5 00a4 a7a7 00a7 aeae 00ae cd66
00000d0 0066 b4b4 00b4 c898 0084 b7b7 00b7 b8b8
00000e0 00b8 b9b9 00b8 b9b9 00b9 caa8 0091 ccb3
00000f0 009a cdb4 009b c1c1 00c1 c2c2 00c2 d7a5
0000100 009a cbcb 00cb d3d1 00b6 cdcd 00cd dea5
0000110 00a2 e0a5 00a5 e1a3 00a3 e0ac 00a8 d3d3
0000120 00d3 d5e6 00c6 d4d4 00d4 d6e7 00c7 d6d6
0000130 00d6 d8e8 00ca d8e8 00cb e7b4 00b4 dce4
0000140 00d5 dcdc 00dc deec 00d3 dfec 00d4 e0ed
0000150 00d5 e0e0 00e0 e6e6 00e6 e7f1 00df eed2
0000160 00d2 f0d3 00d3 eaf3 00e3 ecf4 00e5 f1f7
0000170 00ec f3f7 00ef f4f8 00f0 f6fa 00f4 f8fb
0000180 00f6 f9fb 00f7 fcfd 00fb fdfb 00fb fdfd
0000190 00fc fdfe 00fd fefe 00fe ffff 00ff 0000
00001a0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000430 0000 0000 0000 0000 0000 0000 0000 3b39
0000440 423d 4c47 0f51 0309 0001 3d17 393b 3e3b
0000450 4a44 514e 2e52 293c 0101 4440 3b3e 443d
0000460 4f4b 5652 5756 0533 0425 4b4f 3d44 4a42
0000470 214f 1010 3122 2f05 0a3a 4f52 424a 4e47
0000480 1652 0000 0312 5728 0d27 5256 474e 514c
0000490 1656 0000 2a02 5757 1949 5649 4c51 5250
00004a0 1656 0000 5711 4957 1524 5624 5052 0000
00004b0 0000 0000 5716 4857 1524 5724 5255 5552
00004c0 1657 0000 5716 4957 1524 5724 5255 5250
00004d0 1656 0000 5714 5757 1549 5318 5052 514c
00004e0 1656 0000 450b 5757 1d57 3615 4c51 4e47
00004f0 1652 0000 0841 5746 3f57 1b15 474d 4a42
0000500 204f 0c0c 2541 4107 5657 151c 4230 443d
0000510 4f4b 5552 5756 0623 5238 1537 321a 3e3b
0000520 4a43 514e 5652 1515 1513 1515 2d15 3b39
0000530 423d 4c47 5451 3435 0e1e 261f 2c2b 0000
0000540 0000 0000 0000 0000 0000 0000 0000 0000
*
0000570 0000 0000 0000 0000 0000 0000 0000
000057e

courtesy hexdump, which seems to be, the '*' are folding all-zeros between the nearest addresses. So, lots of, I think unused palette entries, and some padding at the bottom for some reason. Lemme see... there's 88 colors used, and that'll be a 256 color format, so yeah. Heh, which doesn't save any space at all because it has to enumerate as many palette entries as there are pixels in the poor thing, and 24 or 32 bit bitmap would be better.

Anyway, it's lacking the "BM" magic code at the top, and I think the offsets are wrong too (changing the two bytes to "BM" doesn't fix it). In any case, look up file formats, or just save it as whatever and dump that -- the whole file -- to C header. Put that in the packet, with HTTP headers, and it should be fine.

Notably, your first attempt doesn't even contain dimensions or number of colors: just two color entries (but how could anyone know that?) then a bit array (I assume). So there's obviously something wrong there, and it's probably just the proper .ico headers you need.

Tim

Nominal Animal · « **Reply #7 on:** July 05, 2022, 12:14:39 am »

The simple solution is to respond to GET /favicon.ico with the icon data, supplying the length of the data in Content-Length header and the (synthetic or real) modification date in a Date header, and optionally a Cache-control: max-age=seconds header; and to a HEAD /favicon.ico with the same headers but no data. That way, browsers will cache it, and only do a GET or HEAD request at seconds or longer intervals.

Another solution is to embed the favicon data in Base64 format in
<link id="favicon" rel="shortcut icon" type="image/vnd.microsoft.icon" href="data:image/vnd.microsoft.icon;base64,data==">
element in the HTML head section. However, since Base64 encodes three binary bytes in four characters, a 1406-byte favicon will increase each page load by 1963 bytes.

(Some, however, suggest using "image/x-icon" instead of "image/vnd.microsoft.icon". Both seem to work in browsers equally well.)

peter-h · « **Reply #8 on:** July 05, 2022, 07:03:46 am »

The reason I asked here rather than just googling it is because all the hits are ambiguous. They show stuff like

Content-type: text/html

without specifying whether the string is supposed to be followed by a CR, LF, or CRLF. If you get this wrong then obviously the "last char" will be taken as the 1st byte of the binary favicon image.

I now have the favicon being returned without errors

but it doesn't show anywhere in the browser, so it is probably in the wrong format, despite having been generated by a "favicon generator"

I am using

Code: [Select]


static const unsigned char FAVICON_START[] =
"HTTP/1.1 200 OK\r\n"
"Content-type: image/x-icon\r\n";


static const unsigned char FAVICON[] = {
		  0xfb, 0xfb, 0xfb, 0xff, 	// Color of index 0
		  0x6f, 0x6f, 0x6f, 0xff, 	// Color of index 1

		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x2a, 0x80, 0xaa, 0xa0, 0x00,
		  0x00, 0x7f, 0xc0, 0xff, 0xf0, 0x00,
		  0x00, 0xff, 0xe1, 0xff, 0xf8, 0x00,
		  0x00, 0x7f, 0xc0, 0xff, 0xf0, 0x00,
		  0x00, 0x3f, 0x80, 0x7f, 0xa0, 0x00,
		  0x00, 0x1f, 0x00, 0x3e, 0x00, 0x00,
		  0x00, 0x1f, 0x00, 0xbc, 0x00, 0x00,
		  0x00, 0x0f, 0x00, 0xf4, 0x00, 0x00,
		  0x00, 0x1e, 0x01, 0xf0, 0x00, 0x00,
		  0x00, 0x0f, 0x02, 0xe0, 0x00, 0x00,
		  0x00, 0x1e, 0x07, 0xc0, 0x00, 0x00,
		  0x00, 0x0f, 0x0f, 0x00, 0x00, 0x00,
		  0x00, 0x1f, 0x2f, 0x80, 0x00, 0x00,
		  0x00, 0x0f, 0x3c, 0x00, 0x00, 0x00,
		  0x00, 0x1f, 0x7a, 0x00, 0x00, 0x00,
		  0x00, 0x0f, 0xfd, 0x00, 0x00, 0x00,
		  0x00, 0x1f, 0xff, 0x00, 0x00, 0x00,
		  0x00, 0x0f, 0xcf, 0x80, 0x00, 0x00,
		  0x00, 0x1f, 0xe7, 0x40, 0x00, 0x00,
		  0x00, 0x0f, 0x83, 0xe0, 0x00, 0x00,
		  0x00, 0x1f, 0x00, 0xf0, 0x00, 0x00,
		  0x00, 0x0f, 0x01, 0xf4, 0x00, 0x00,
		  0x00, 0x1e, 0x00, 0x3c, 0x00, 0x00,
		  0x00, 0x0f, 0x00, 0x3e, 0x00, 0x00,
		  0x00, 0x1e, 0x00, 0x1d, 0x00, 0x00,
		  0x00, 0x0f, 0x00, 0x0f, 0x80, 0x00,
		  0x00, 0x1f, 0x00, 0x07, 0xc0, 0x00,
		  0x00, 0x3f, 0x80, 0x07, 0xe0, 0x00,
		  0x00, 0x7f, 0xc0, 0x07, 0xf0, 0x00,
		  0x00, 0xff, 0xe0, 0x03, 0xf8, 0x00,
		  0x00, 0x7f, 0xc0, 0x03, 0xf0, 0x00,
		  0x00, 0x2a, 0x80, 0x01, 0x50, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		};

and I have tried it with all 3 options for the end of the line before the file.

The file itself is indexed colour, 2 colours, for the smallest possible filesize. But maybe that doesn't work. What is the smallest favicon option?

Also it appears that Chrome does not cache the favicon as default behaviour so I went looking for caching directives and there are about 1000 of them online

Firefox reportedly does cache it, and I can confirm that. But it also doesn't show it.

ataradov · « **Reply #9 on:** July 05, 2022, 07:11:55 am »

Quote from: peter-h on July 05, 2022, 07:03:46 am

without specifying whether the string is supposed to be followed by a CR, LF, or CRLF.

This is specified in the standard - https://www.rfc-editor.org/rfc/rfc2616#section-2.2

HTTP always uses CRLF as a line ending.

Quote from: peter-h on July 05, 2022, 07:03:46 am

but it doesn't show anywhere in the browser, so it is probably in the wrong format, despite having been generated by a "favicon generator"

Can the browser open your link directly from the address bar?

Quote from: peter-h on July 05, 2022, 07:03:46 am

The file itself is indexed colour, 2 colours, for the smallest possible filesize. But maybe that doesn't work. What is the smallest favicon option?

Minimal PNG file is about 70 bytes. Single pixel GIF is 42 bytes.

And it looks like people actually came up with 35 byte GIFs. This is something you can just inline in the HTML as a Base64 string like Nominal Animal suggested. It an overhead that is smaller in size than HTTP headers in the response for the favicon.

peter-h · « **Reply #10 on:** July 05, 2022, 07:54:40 am »

The link from the address bar doesn't work either.

Chrome shows a blank page.

FF says Image ... can't be displayed because it contains errors.

So I need to revisit the encoder(s) again.

ataradov · « **Reply #11 on:** July 05, 2022, 08:04:26 am »

Displaying it from the address bar is the best test. Once that works, regular request would work too.

Your debug screenshot shows 52 bytes. This is clearly wrong. So you are either returning the wrong Content-Length or incomplete data.

AndyBeez · « **Reply #12 on:** July 05, 2022, 08:15:53 am »

A favicon can be any image file. You can use SVG, PNG, GIF and ICO formats on most browsers. Use the binary for a PNG as this is the most universally supported format.

RTFM : https://en.m.wikipedia.org/wiki/Favicon

peter-h · « **Reply #13 on:** July 05, 2022, 08:25:22 am »

I am not returning a content length. Most of the examples don't suggest this is required.

Googling suggests 16x16 and .ico format in 8 bit colour is correct. However I have tried dozens of things now and nothing works. I am just after a simple letter "K"

(that one is 16x16)

Is there nothing after the binary block?

This is my last try - a PNG

Code: [Select]

static const unsigned char FAVICON_START[] =
"HTTP/1.1 200 OK\r\n"
"Content-type: image/x-icon\r\n";


static const unsigned char FAVICON[] = {
		  0xff, 0xff, 0xff, 0xff, 	/*Color of index 0*/
		  0x02, 0x02, 0x10, 0xff, 	/*Color of index 1*/

		  0x00, 0x00,
		  0x00, 0x00,
		  0x00, 0x00,
		  0x1c, 0xf0,
		  0x08, 0x40,
		  0x08, 0x80,
		  0x09, 0x00,
		  0x0a, 0x00,
		  0x0d, 0x00,
		  0x08, 0x80,
		  0x08, 0x40,
		  0x08, 0x20,
		  0x1c, 0x30,
		  0x00, 0x00,
		  0x00, 0x00,
		  0x00, 0x00,
		};

ataradov · « **Reply #14 on:** July 05, 2022, 08:30:42 am »

Content-Length is required for all responses containing Entity-Body. This is a TCP connection there is no way to determine the length of arbitrary binary data.

Also "Content-Type" must be spelled like this. You lave a lower case "t". EDIT: Although it looks like HTTP is not case sensitive, so that's not an issue.

AndyBeez · « **Reply #15 on:** July 05, 2022, 08:36:40 am »

Your web server should list .ico types in the hosting config, as this is not strickly a default file type. Also the favicon needs to be in the correct directory for the '/' path.

ataradov · « **Reply #16 on:** July 05, 2022, 08:41:31 am »

Based on the question and constraints, this is served by a custom server, possibly on an embedded system.

peter-h · « **Reply #17 on:** July 05, 2022, 08:43:44 am »

This is an embedded system, not Apache or similar server from where the client can fetch files from a dir path. I am looking for

Code: [Select]

if(strncmp(buf, "GET /favicon.ico", 16) == 0)
and then returning the favicon. Same code for returning the main page (name.html) and that works. Debugging confirms this stuff is working right; at least I am returning the right sizes.

Is the content length just the binary data?

Just realised that my header is probably wrong for a .png file format. Previously I was using a .ico file format.

ataradov · « **Reply #18 on:** July 05, 2022, 08:52:13 am »

https://datatracker.ietf.org/doc/html/rfc2616#section-14.13

It is mandatory for most responses. The only time it is not necessary for responses containing the data is if a chunked encoding is used. This is useful for streaming data, but then you have to specify chunk lengths.

Conent-Length covers all octets after the response header (ending in CRLF).

Your template does not have the final CRLF. Do you actually send it? Response header ends in an empty line.

peter-h · « **Reply #19 on:** July 05, 2022, 09:04:10 am »

This really simple thing is amazingly complicated.

Code: [Select]

static const unsigned char FAVICON_HEADER[] =
"HTTP/1.1 200 OK\r\n"
"Content-Type: image/x-png\r\n"
"Content-length: 40\r\n";


static const unsigned char FAVICON_BODY[] = {
		  0xff, 0xff, 0xff, 0xff, 	/*Color of index 0*/
		  0x02, 0x02, 0x10, 0xff, 	/*Color of index 1*/

		  0x00, 0x00,
		  0x00, 0x00,
		  0x00, 0x00,
		  0x1c, 0xf0,
		  0x08, 0x40,
		  0x08, 0x80,
		  0x09, 0x00,
		  0x0a, 0x00,
		  0x0d, 0x00,
		  0x08, 0x80,
		  0x08, 0x40,
		  0x08, 0x20,
		  0x1c, 0x30,
		  0x00, 0x00,
		  0x00, 0x00,
		  0x00, 0x00,
		};

Still no luck. Chrome has changed the frequency at which it fetches the favicon. It now looks like it has seen so many errors it has largely given up fetching it, so I am testing with FF also.

A direct file fetch produces this

where the length value doesn't make much sense. I am using the same code as for the main page

Code: [Select]

	  netconn_write(conn, FAVICON_HEADER, strlen((char*)FAVICON_HEADER), NETCONN_COPY);
	  netconn_write(conn, FAVICON_BODY, sizeof(FAVICON_BODY), NETCONN_COPY);  // strlen doesn't work with binary data

The sizeof is 40 which is right.

However, using

Code: [Select]

	  netconn_write(conn, FAVICON_HEADER, strlen((char*)FAVICON_HEADER), NETCONN_COPY);
	  netconn_write(conn, FAVICON_BODY, sizeof((char*)FAVICON_BODY), NETCONN_COPY);

returns 68 bytes. I thought the sizeof() operator would work simply on the array, which is 40 long, so (char *) should not affect the value.

I now wonder if favicon.ico is right when the file is actually in png format?

This looks like another 1-2 day rabbit hole

AndyBeez · « **Reply #20 on:** July 05, 2022, 09:19:42 am »

Does your Chrome or Firefox have a debug mode? Can you view the raw http responses?

sokoloff · « **Reply #21 on:** July 05, 2022, 09:30:55 am »

Quote from: peter-h on July 05, 2022, 09:04:10 am

I thought the sizeof() operator would work simply on the array, which is 40 long, so (char *) should not affect the value.

sizeof of a char * will be the size of a pointer on your platform, not the size of the thing that pointer is pointing to (which is not known after the cast to a char* )

peter-h · « **Reply #22 on:** July 05, 2022, 10:07:31 am »

Quote

Does your Chrome or Firefox have a debug mode? Can you view the raw http responses?

Chrome seems to but it displays a blank. Same with Edge.

There is something very basic going wrong here.

Nothing useful online because all google hits are based around normal web servers where you just create the favicon file and drop it somewhere.

T3sl4co1l · « **Reply #23 on:** July 05, 2022, 10:36:26 am »

What tools are you using, for image editing, conversion and "favicon generator"?

You linked a 46x44 image which is a capital 'K' on white background, 16x16, on black background 46x44.

FYI, the PNG format, cropped to 16x16, saved as 2-color format in PSP7 (and again as hexdump shows it) is:

Code: [Select]

0000000 5089 474e 0a0d 0a1a 0000 0d00 4849 5244
0000010 0000 1000 0000 1000 0301 0000 2500 6d3d
0000020 0022 0000 742b 5845 4374 6572 7461 6f69
0000030 206e 6954 656d 5400 6575 3520 4a20 6c75
0000040 3220 3230 2032 3530 323a 3a32 3835 2d20
0000050 3630 3030 c8d8 b19c 0000 0700 4974 454d
0000060 e607 0507 180a 8b1f 6eb3 0067 0000 7009
0000070 5948 0073 0b00 0012 0b00 0112 ddd2 fc7e
0000080 0000 0400 4167 414d 0000 8fb1 fc0b 0561
0000090 0000 0600 4c50 4554 0000 ff00 ffff d9a5
00000a0 dd9f 0000 2b00 4449 5441 da78 f863 9fff
00000b0 8201 f31e 7c33 cfdf bdf0 e19e 7fdb af86
00000c0 19ff fd3e b107 2241 19f7 9f1e 8067 0329
00000d0 a500 1c5e 53a1 edb2 0055 0000 4900 4e45
00000e0 ae44 6042 0082
00000e5

There's no weird formatting of colors or arrays of bits, there's, well there is a "PNG" near the top, and a few other bits of junk in there actually by the look of it, you can shave those out I'm sure with a compactor tool -- let me see here. Ah, https://tinypng.com/ seems to do a good enough job of it. And it still opens in PSP7 which is good enough for me:

Code: [Select]

0000000 5089 474e 0a0d 0a1a 0000 0d00 4849 5244
0000010 0000 1000 0000 1000 0301 0000 2500 6d3d
0000020 0022 0000 5006 544c ff45 ffff 0000 5500
0000030 d3c2 007e 0000 4925 4144 0854 63d7 0380
0000040 0f99 1c0c 0c0e 0d1c 9c0c 0c0c 0c5c bc0c
0000050 400c 5836 8144 c641 ae00 000a 2058 4103
0000060 b764 72b3 0000 0000 4549 444e 42ae 8260
0000070

Should be, paste that in there with the right length (0x70 = 112 bytes) and go. Well, edit it for commas and 0x's obviously...

Yeah I don't have a clue where you're getting your raw image data from but it sure as hell ain't any supported image format

Tim

peter-h · « **Reply #24 on:** July 05, 2022, 10:43:23 am »

I've tried various online tools, with .bmp .png and last .ico files, converting to "C array".

The source files are ex photoshop, 16x16 pixel. Yes the last one I posted was bigger but that was just so you could see it in the post. The actual image is 16x16 pixels.

There is a lot of conflicting info on acceptable formats.

I am now using this 256-byte one, converted with https://lvgl.io/tools/imageconverter

Code: [Select]

static const unsigned char FAVICON_HEADER[] =
"HTTP/1.1 200 OK\r\n"
"Content-Type: image/x-icon\r\n"
"Content-Length: 256\r\n";


static const unsigned char FAVICON_BODY[] = {
		  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0x20, 0x20, 0x20, 0xff, 0xff, 0x20, 0x20, 0x20, 0x20, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0x20, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0x20, 0x20, 0x20, 0xff, 0xff, 0xff, 0xff, 0x20, 0x20, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
		};

which in Edge produces this in the debug console

and the header and the file are 66 and 256 bytes which comes to 322 so that's ok. I've checked the length value passed here

Code: [Select]

	  netconn_write(conn, FAVICON_HEADER, strlen((char*)FAVICON_HEADER), NETCONN_COPY);
	  netconn_write(conn, FAVICON_BODY, sizeof(FAVICON_BODY), NETCONN_COPY);

Chrome and Edge show nothing (if going to the direct URL) while FF says the image contains errors. I can't see any way to display the actual binary data coming back to the browser, and I don't have an ethernet protocol analyser.

I did try your file, with

Code: [Select]

		0x5089, 0x474e, 0x0a0d, 0x0a1a, 0x0000, 0x0d00, 0x4849, 0x5244,
		0x0000, 0x1000, 0x0000, 0x1000, 0x0301, 0x0000, 0x2500, 0x6d3d,
		0x0022, 0x0000, 0x5006, 0x544c, 0xff45, 0xffff, 0x0000, 0x5500,
		0xd3c2, 0x007e, 0x0000, 0x4925, 0x4144, 0x0854, 0x63d7, 0x0380,
		0x0f99, 0x1c0c, 0x0c0e, 0x0d1c, 0x9c0c, 0x0c0c, 0x0c5c, 0xbc0c,
		0x400c, 0x5836, 0x8144, 0xc641, 0xae00, 0x000a, 0x2058, 0x4103,
		0xb764, 0x72b3, 0x0000, 0x0000, 0x4549, 0x444e, 0x42ae, 0x8260
		};

but it completely breaks it. I declared the array as uint16_t because I can see e.g. 0x0a0d which is LFCR i.e. backwards but the 32F4 is little-endian so it should work.

If someone would be kind enough and generate an icon file C array which just displays the letter K (in Courier, fwiw) I will give it a go but otherwise I will have to abandon this, after 2 days. It is very easy on a normal web server but clearly there is some special trick involved when one is dealing with "actual bytes".

At the same time I am returning a printable-data web page without any trouble, so maybe base64 encoding would be better. OTOH I don't know if my icon file is even right...

I've been looking for somebody, as a paid consultant, who can help with this kind of thing but haven't found anyone. There is a Monday-only guy working on this project (he did the original Cube setup and later worked on the ethernet end of it) and he knows all this, but today is Tuesday

So I need to solve these things on my own. I can do most things in embedded but by choice never went up the learning curve on ETH, USB, TCP etc, PHP, server-side coding and config. I do have a good guy for the server stuff and he is doing some embedded C now (setting up an embedded HTTP server on this product) but I think this favicon issue is something really simple.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: What actual data is used to return a favicon to the browser? (Read 4539 times)

Share me