[参考译文] CC3220S-LAUNCHXL：将获取天气示例与新的 HTTP API 结合使用

尊敬的 Jack：

您的移植代码到底在哪里发生了故障？ 是否有特定的 HttpClient 调用失败？ 如果是、您得到的错误代码是什么？ 您是否还尝试使用调试器单步执行失败的函数调用、并查看导致其失败的底层套接字错误是什么？

此致、
Michael

我在下面的代码中得到了错误、您可以在 GitHub 链接的第227行中看到该错误。

lRetVal = HttpClient_sendRequest (CLI、http_method_get、acSendBuff、NULL、0、0)；
如果(lRetVal < 0)
｛
//uart_print ("发送 HTTP 1.1 GET 请求失败。\n\n");
返回 SERVER_GET_WEATE_FAILED；
｝ 

好的，从 HttpClient_sendRequest()获取的错误代码是什么？ 此外，如果您单步执行该函数，导致 HttpClient_sendRequest()失败的潜在错误是什么？ 若要查找此内容、请将 SDK 中/source/ti/net/http 的 httpclient.c 复制到您的项目中。 然后，您应该能够完全单步执行 HttpClient_sendRequest()，并从中找到导致它失败和调试的确切原因。

此致、
Michael

Michael Reymond 收到错误代码-3018。 sendRequest 函数中的错误如下所示。

/*块化状态*/
其他
｛
/*有效性检查*/
if ((flags & HttpClient_chunch_start)||(NULL ==正文)
｛
返回(HttpClient_EWRONGAPIPARAMETER)；
｝
｝ 

我尝试了您的修复、但不幸的是、它不起作用。 以下是上断点的图像

HttpClient_CB *CLI =(HttpClient_CB *) client； 

一个断点。 您能告诉我们问题可能是什么吗？

尊敬的 Jack：

您的第一个屏幕截图并不是最有用的、因为您在初始化 CLI 之前捕获了 CLI 的状态。 当断点在语句上停止时、它将执行该语句、但尚未执行。

您的第二个屏幕截图显示 CLI 现在已初始化为对我来说更可信的内容。 但是，sendRequest()中可能还有其他导致问题的东西。 您是否会得到与以前相同的误差？ 如果跟踪并单步执行 sendRequest()，则哪个函数调用或行会抛出错误？

此致、
Michael

我发现在以下代码中出现问题后。 程序只需输入"else"语句、"Breaks"、然后返回401的状态。

if (getCliState (CLI、enable_redirect_State)&&(isRedirect (status)))
｛
if (getCliState (CLI、location_added_State))
｛
/*如果在内部过滤了位置标头，请将其从过滤器列表中去除*/
cli->responseHFieldFilter &=~(NumberToBitField (HttpClient_HFIELD_RES_LOCATION)；
setCliState (CLI、location_added_State、false)；
｝
if (redirectFlag & Incomplete_location)
｛
/*位置标头不完整重定向是不可接受的*/
return( HttpClient_EREDIRECTLOCATIONFAIL )；
}
if (redirectCount < HttpClient_MAX_redirective_Attempts)
｛
RET =重定向(CLI、状态、方法)；
如果(RET < 0)
｛
return (ret)；
｝
｝
redirectCount++；
｝
否则((status =HTTP_SC_unauthorized)&&(cli->httpAuthCallback != NULL))
｛
/*检查 www.-authenticate 是否是有效的响应标头*/
if (((cli->responseHeaderMap[WWW_Authenticate_hash-index]！= NULL)&&(strstr (cli->responseHeaderMap[WWW_Authenticate_hash-index]、"HttpClient_ERESPONSEVALUEBUFSMALL")= NULL))
｛
/*执行用户注册的身份验证回调*/
RET = cli->httpAuthCallback (cli->responseHeaderMap[WWW_Authenticate_hash-index]、strlen (cli->responseHeaderMap[WWW_Authenticate_hash-index])、buf、&bufLen)；
如果(RET < 0)
｛
return (ret)；
｝
/*添加客户端授权请求标头*/
RET = HttpClient_setHeader (CLI、HttpClient_HFIELD_REQ_authorization、buf、bufLen、HttpClient_HFIELD_not _persistent)；
/*如果使用的方法是 HEAD，即使存在内容长度标头，服务器也不会发送正文*/
if (strcmp (method、http_method_head)！= 0)
｛
/*刷新响应的主体(如果存在) *
操作
｛
RET = HttpClient_readResponseBody (CLI、buf、HttpClient_BUF_LEN、&M 标志)；
如果(RET < 0)
｛
返回(RET)；
｝
} while (((ret >0)&& moreFlag)；
}
其他
｛
cli->bodyLen = 0;
}
｝
/*停止 do while 循环并退出 sendRequest()函数，以便重新发送请求
使用生成的授权标头*/
中断；
｝
其他
｛
中断；
｝ 

Michael Reymond Hi。 对此进行了任何更新？

尊敬的 Jack：

如果您获得的状态为401、则表示 http 请求已成功完成、但状态为"401未授权"。 在某种程度上，您正在联系的 http 服务器正在通过要求客户端提供身份验证凭据来响应您的请求。

如果 CC3200示例仍然正常工作、则表明您的终端上仍然存在 CC3220 http 客户端配置错误 您可以尝试精确定位可能出现问题的一种方法是转储 HTTP 请求的内容和您对 UART 的响应。 如果您转储在 CC3220和 CC3200上发送的请求并比较这两者、我怀疑您会发现一些差异、从而解释您所得到的错误。

在 CC3220上、转储 HTTP 请求的最简单方法是修改 httpclient.c 中的 sprint()函数 只需在 slNetSock_send()调用之后在 cli->validBufStart 上添加 Display_printf()调用。 这应该会打印出您要发送到服务器的任何内容。 在 CC3200上，您可以使用 UART_PRINT()执行类似的操作。

如果您没有可运行此测试的 CC3200、您还可以使用 PC 实用程序、例如 cURL：
https://curl.haxx.se/

尝试转储请求、看看是否有明显的情况会导致您从连接的服务器收到401错误。

此致、
Michael

Michael Reymond 

当您说"如果您没有可运行此测试的 CC3200、您还可以使用诸如 cURL 之类的 PC 实用程序"时、您要求我做什么？

下面是我从 CC3220收到的消息。 请求可能有什么问题？

获取/data/2.5/weather?q=Salem mode=xml&units=tiper&appId= HTTP/1.1
主机：HttpClient (ARM；TI-RTOS)¾¾¾¾¾¾¾°k
主机：api.openweathermap.org

有关详细信息、请参阅 openweathermap.org/faq。"｝ 

尊敬的 Jack：

因此、当我传递了不正确的 API 密钥时、我测试了 cURL 并得到了此响应：

C：\Users\a0232058\Downloads\cur-7.54.0-win64-MinGw\cur-7.54.0-win64-MinGw>curl -G"api.openweathermap.org/.../weather --proxy http://wwwgate.ti.com:80/ -v
*正在尝试10.248.194.19...
* tcp_NODELAY 设置
*连接到 wwwgate.ti.com (10.248.194.19)端口80 (#0)
>获取 api.openweathermap.org/.../weather HTTP/1.1
>主机：api.openweathermap.org
>用户代理：c卷 曲/7.54.0>
接受：*/*
>代理连接：保持活动
>
< HTTP/1.1 401未经授权
<通过1.1 10.248.194.19 (McAfee Web Gateway
2018
年10月27日< GMT 238.41：星期一：215.0) openresty
< X-Cache：从10.248.194.19错过
< X-Cache - Key：/data/2.5/weather?mode=xml &q=Salem &units=英制
< Content-Type：application/json；charset=UTF-8
< Content-Length：107
< Proxy-Connection：keep-alive
< Access-Control-allent-origin：*
< Access-Control-allow-methods：get、"ccentials"


、"ccentials"、"Get-capacitivity"、"Cod：try"、"try"、"tradement-try"、"its"、"API"。 有关  更多信息，请参见 openweathermap.org/faq。"}*保留用于承载 wwwgate.ti.com 的连接#0 

这与之前观察到的401误差一致。

但是、当我注册并传递正确的授权密钥时、我得到以下输出：

C：\Users\a0232058\Downloads\cur-7.54.0-win64-MinGw\cur-7.54.0-win64-MinGw>curl -G"api.openweathermap.org/.../weather --proxy http://wwwgate.ti.com:80/ -v
*正在尝试10.248.194.18...
* tcp_NODELAY 设置
*连接到 wwwgate.ti.com (10.248.194.18)端口80 (#0)
>获取 api.openweathermap.org/.../weather HTTP/1.1
>主机：api.openweathermap.org
>用户代理：c卷 曲/7.54.0>
接受：*/*
>代理连接：保持活动
>
< HTTP/1.1 200正常
<通过：1.1 10.248.194.18 (McAfee Web Gateway
2018
< GMT 2.59：14)服务器：< openresty
< X-Cache：从10.248.194.18缺失
< X-Cache -密钥：/data/2.5/weather?APPID=59acd840241603ed1f973173a73072cb &mode=xml&q=Dallas&units=英制
< Content-Type：application/xml；charset=UTF-8
< Content-Length：771
< Proxy-Connection：Keep-Alive
< Access-Control-allow-origin：*
< Access-Control-allow-allow-Get-Control

<允许访问后凭据

美国 *主机 wwwgate.ti.com 的连接#0保持不变 

我会仔细检查您使用的 API 密钥、并确保在您的 CC3220示例中正确提供该密钥。 请注意、API 密钥激活之前需要一些时间(对我来说是~1小时左右)。 如果您立即尝试使用 API 密钥、请再试一次、看看会发生什么情况。

此致、

Michael

Michael Reymond 、我注意到您的响应(使用无效的 API 密钥)比我的响应时间长。 为什么会这样呢？ 您是否在 CC3220或 CC3200上进行了测试？

非常感谢。 它现在可以工作了。 我试了一下您的 API 密钥、然后我的。 它们都可以正常工作-我的 API 密钥可能需要一段时间才能工作。