BUG: Websocket transport should allow case-insensitive HTTP header lookups (IDFGH-665)

[bverhoeven]

Per the HTTP RFC, header field names are case-insensitive:

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

However, ESP-IDF's websocket implementation in the transport_tcp component uses its get_http_header function to get the value of the 'Sec-Websocket-Accept' in a case-sensitive manner by looking for the requested header using strstr.

This is causing valid responses, like below, to be rejected with a "Sec-WebSocket-Accept not found" error:

HTTP/1.1 101 Switching Protocols
connection: Upgrade
sec-websocket-protocol: mqtt
upgrade: websocket
sec-websocket-accept: ERt2/04pC/rOP8P0YlNFyHWld7A=

This error is caused by this call to get_http_header:

esp-idf/components/tcp_transport/transport_ws.c

Lines 119 to 123 in 140b6e3

	char *server_key = get_http_header(ws->buffer, "Sec-WebSocket-Accept:");
	if (server_key == NULL) {
	ESP_LOGE(TAG, "Sec-WebSocket-Accept not found");
	return -1;
	}

As can be seen, the get_http_header function, as shown below, uses strstr (the first one) to find the substring in the given buffer:

esp-idf/components/tcp_transport/transport_ws.c

Lines 64 to 77 in 140b6e3

	static char *get_http_header(const char *buffer, const char *key)
	{
	char *found = strstr(buffer, key);
	if (found) {
	found += strlen(key);
	char *found_end = strstr(found, "\r\n");
	if (found_end) {
	found_end[0] = 0;//terminal string
	return trimwhitespace(found);
	}
	}
	return NULL;
	}

As strstr is case-sensitive, this call will fail to find the "sec-websocket-accept" header because it's looking for "Sec-Websocket-Accept".

This seems to be trivially fixed by using a case-insensitive method, such as strcasestr (and that's something I've done locally) but that function only seems to be available when compiling with _GNU_SOURCE (or the likes) defined and that doesn't seem to happen anywhere within the IDF so I'm hesitant to try that without knowing the implications.

Pointers would be appreciated.