[参考译文] CC3235SF：解析 HTTP 元数据 TLV

我们将对此进行仔细检查、并在 此处报告结果。

您好、Kobi、

如果您仔细查看"parseHttpRequestMetadata"中的代码、

类型和长度定义为 ：   

uint16_t 元件类型；
uint16_t len；

16为2个字节...

可能 HTTP pMetadata 中的 TLV 正常。 但是 ArgvCallback 的解析和构造似乎与...不同。

但下面是"sl_NetApp_Request_metadata_type_HTTP_content_LEN"切换案例，它将解析描述为 ：

(*argcCallback)++;
/* add content type */
elementType = setElementType(1, *requestIdx,
CONTENT_LEN_TYPE);
sl_Memcpy((uint8_t* )argvArray, (uint8_t* )&elementType,
		  ARGV_LEN_OFFSET);
argvArray += ARGV_LEN_OFFSET;
*argvArray++ = len; /* add content length */
sl_Memcpy((uint8_t* )argvArray, pTlv, len);
sl_Memcpy((uint8_t* )&value, pTlv, len);

它被显式写入(sl_memcpy ((uint8_t*) argvArray、(uint8_t*)和 ElementType、
                         argv_LEN_offset)；) 在元素类型中存储2个字节！

阵列的波束结构如下：

跳过上述2个字节 ： argvArray += ARGV_LEN_OFFSET；

仅用1个字节复制长度 ：*argvArray++= len；/*添加内容长度*/

 复制实际值： sl_memcpy((uint8_t*) argvArray、pTlv、len);

此 argvArray 也用于 parseUrlEncoded...

即使"setElementType"方法返回16位类型...

你好，Kobi；)

感谢您、我可以看到代码中有两个内部 TLV 结构。

那么，这两种类型和长度之间没有直接的联系？

没有发生不良铸造情况的机会？

此致、

特奥多尔