[问答]

TCPIP_HTTP_NET_ConnectionCallbackPosGet问题？

1579 HTTP

问答对人有帮助，内容完整，我也想知道答案 0 我正在移植一个旧的应用程序（2.06）。最近，我发现了一种模拟HTLA和HTTP网络服务器的MLLA库（HhttpPrimtPythiCixVar（））的CurHTHTP.CalbPoS机制。服务器和两个调用HTTP网络服务器的TCPIpHIPHtpNETHelnCalutalCalpRouthPoGet和TCPPIpHhttpNETSnEngulalCalkRouthSet。在我的项目中，我使用HTTP网络服务器使用HTTPS连接。但是，TCPIPHHTPNETNEnnLognCalnCouthPosiGET始终返回零。下面看我的测试代码，我猜它是正确的，我可能错了。可能主要的问题是在调用用户函数之前总是将No.HtpHyDyvCARLACKEDHONPHTPCON & & CalbPoPs设置为零。它是错误的和谐还是我做错了什么？以上来自于百度翻译以下为原文 I am porting an old application in HARMony (2.06). Recently I discovered a legacy mechanism to emulate the curHTTP.callbackPos of MLA libraries (HTTPPrint_dynamic_var()) in Harmony for both HTTP and HTTP NET servers. I found that there are two calls TCPIP_HTTP_CurrentConnectionCallbackPosGet and TCPIP_HTTP_CurrentConnectionCallbackPosSet for the HTTP server and two calls TCPIP_HTTP_NET_ConnectionCallbackPosGet and TCPIP_HTTP_NET_ConnectionCallbackPosSet for the HTTP NET server. In my project, I am using HTTP NET server to use HTTPS connections. However, TCPIP_HTTP_NET_ConnectionCallbackPosGet always returns zero. See below my test code, I guess that it is correct, I may wrong. TCPIP_HTTP_DYN_PRINT_RES TCPIP_HTTP_Print_net(TCPIP_HTTP_NET_CONN_HANDLE connHandle, const TCPIP_HTTP_DYN_VAR_DCPT vDcpt) { #define DATA_SIZE 1024// 1 kBytes TCPIP_HTTP_DYN_PRINT_RES rtn; HTTP_APP_CALLBACK_POS pos; uint32_t len; if ((pos = (HTTP_APP_CALLBACK_POS ) TCPIP_HTTP_NET_ConnectionCallbackPosGet(connHandle)) == NULL) { pos = (HTTP_APP_CALLBACK_POS) x_malloc(sizeof (HTTP_APP_CALLBACK_POS)); pos->size = pos->sm = 0; } switch (pos->sm) { case 0: pos->data = x_malloc(sizeof (char) DATA_SIZE); len = SettingsToXML_GetNet(pos->data, sizeof (char) DATA_SIZE); TCPIP_HTTP_NET_DynamicWrite(vDcpt, pos->data, len, false); pos->sm++; rtn = TCPIP_HTTP_DYN_PRINT_RES_DONE; // This must be RES_DONE because I am using TCPIP_HTTP_NET_ConnectionCallbackPosSet break; case 1: // If here the buffer may be released x_free(pos->data); x_free(pos); pos = NULL; TCPIP_HTTP_NET_ConnectionCallbackPosSet(connHandle, NULL); rtn = TCPIP_HTTP_DYN_PRINT_RES_DONE; break; } TCPIP_HTTP_NET_ConnectionCallbackPosSet(connHandle, (uint32_t) pos); return rtn; } Probably the main problem is in _HTTP_DynVarCallback where pHttpCon->callbackPos is always set to zero before calling user functions. Is it a bug in Harmony or am I doing something wrong? static TCPIP_HTTP_CHUNK_RES _HTTP_DynVarCallback(TCPIP_HTTP_NET_CONN* pHttpCon, TCPIP_HTTP_CHUNK_DCPT* pChDcpt) { TCPIP_HTTP_DYN_PRINT_RES printRes; const TCPIP_HTTP_DYN_VAR_KEYWORD_ENTRY* pKEntry; TCPIP_HTTP_DYNVAR_CHUNK_DCPT* pDynChunkDcpt; TCPIP_HTTP_DYN_VAR_DCPT* pDynDcpt; pDynChunkDcpt = &pChDcpt->dynChDcpt; pDynDcpt = &pDynChunkDcpt->pDynAllocDcpt->dynDcpt; printRes = TCPIP_HTTP_DYN_PRINT_RES_DONE; pHttpCon->callbackPos = 0; if((pChDcpt->flags & TCPIP_HTTP_CHUNK_FLAG_DYNVAR_DEFAULT_PROCESS) == 0) { // call the user processing if(!_HTTP_DbgKillUserDynVar()) { printRes = (httpUserCback->dynamicPrint)(pHttpCon, pDynDcpt, httpUserCback); _HTTP_DynDbgCallback(pDynDcpt->dynName, printRes, pHttpCon->connIx); if(printRes == TCPIP_HTTP_DYN_PRINT_RES_DEFAULT) { pChDcpt->flags \|= TCPIP_HTTP_CHUNK_FLAG_DYNVAR_DEFAULT_PROCESS; } else if(printRes == TCPIP_HTTP_DYN_PRINT_RES_AGAIN \|\| printRes == TCPIP_HTTP_DYN_PRINT_RES_PROCESS_AGAIN) { if(++pDynChunkDcpt->dynRetries > httpDynVarRetries) { printRes = TCPIP_HTTP_DYN_PRINT_RES_DONE; _HTTP_Report_ConnectionEvent(pHttpCon, TCPIP_HTTP_NET_EVENT_DYNVAR_RETRIES_EXCEEDED, pDynDcpt->dynName); } } } } if((pChDcpt->flags & TCPIP_HTTP_CHUNK_FLAG_DYNVAR_DEFAULT_PROCESS) != 0) { // call the default implementation! if((pKEntry = pDynChunkDcpt->pKEntry) != 0) { printRes = (pKEntry->dynamicPrint)(pHttpCon, pDynDcpt, httpUserCback); _HTTP_DynDbgCallback(pDynDcpt->dynName, printRes, pHttpCon->connIx); } } if(pHttpCon->callbackPos != 0) { // user messing with the callbackPos; ignore the printRes printRes = TCPIP_HTTP_DYN_PRINT_RES_PROCESS_AGAIN; } pChDcpt->flags &= ~TCPIP_HTTP_CHUNK_FLAG_DYNVAR_AGAIN; if(printRes == TCPIP_HTTP_DYN_PRINT_RES_AGAIN \|\| printRes == TCPIP_HTTP_DYN_PRINT_RES_PROCESS_AGAIN) { pChDcpt->flags \|= TCPIP_HTTP_CHUNK_FLAG_DYNVAR_AGAIN; return printRes == TCPIP_HTTP_DYN_PRINT_RES_AGAIN ? TCPIP_HTTP_CHUNK_RES_WAIT : TCPIP_HTTP_CHUNK_RES_OK; } // don't need calling again return TCPIP_HTTP_CHUNK_RES_DONE; } 0
2018-8-31 15:32:24　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × qun333 该类别下有 57 个回答。邀请回答技术发广告该类别下有 56 个回答。邀请回答 caoguiqun 该类别下有 56 个回答。邀请回答 psw30 该类别下有 44 个回答。邀请回答伊丹姿子该类别下有 41 个回答。邀请回答 uwufwjrw 该类别下有 39 个回答。邀请回答 hetao1111 该类别下有 38 个回答。邀请回答 lc123617 该类别下有 35 个回答。邀请回答欧阳大大该类别下有 32 个回答。邀请回答作死不止该类别下有 31 个回答。邀请回答 asd010 该类别下有 31 个回答。邀请回答 60user92 该类别下有 29 个回答。邀请回答 wy8719 该类别下有 29 个回答。邀请回答 haikitty 该类别下有 28 个回答。邀请回答 ju978779 该类别下有 28 个回答。邀请回答嘻嘻爱哈哈该类别下有 28 个回答。邀请回答 xiuzhen122 该类别下有 27 个回答。邀请回答 pol666 该类别下有 27 个回答。邀请回答 ueywyrsdfs 该类别下有 26 个回答。邀请回答 lhly23 该类别下有 25 个回答。邀请回答举报孙伟相关推荐 • 从http迁移到http_net时编译失败 1057 • HTTPPrint什么是DIAKACK参数 1694 • 只有一个客户端可以连接到HTTP网络Web服务器 1589 • NET_PRES_SKT_OP._TYPE的定义是什么？ 1432 • 将HTTP Server添加到项目中时出错 934 • TCPIP_DHCP_Enable（）成功的要求是什么？ 1820 • 当调用TCPIP_DHCP_IsServerDetected()函数时总是返回0 1490 • 为什么Harmony提供关闭/禁用HTTP的用户选项的任何提示 959 • TCPIP_STACK_Deinitialize（）失败，堆删除失败 2546 • TCPIP MDNS ServiceRegister未注册第二个服务 2685 1个回答

答案对人有帮助，有参考价值 0 我将每次查看CaleBoPs设置为0，看看它是否是一个bug，我会让你知道我发现了什么。但是，对于你的使用示例，如果这是你在你的应用程序中真正使用的，我认为使用DyPosiNe函数将更容易。T（…）{OLC；CaltTCPIpHutpHypNETRealDead（，，true）；//您需要返回完成；}确认函数释放缓冲区。请参阅它，看看逻辑中是否有一些bug。显然，另一种方法是依靠本地维护的数据来决定分配/释放和使用回调位置，以便将意图传达给HTTPNET。以上来自于百度翻译以下为原文 I'll be looking into the setting of the callbackPos to 0 each time, to see if it's a bug and I'll let you know what I find. However, for your usage example, if this is what you really use in your app, I think it would be much easier to use the DynPrint function as it was intended: TCPIP_HTTP_Print_net(...) { alloc; call TCPIP_HTTP_NET_DynamicWrite(,,, true); // you need ack return done; } And the acknowledge function just frees the buffer. A simple example of how to use the acknowledge function to manipulate statically allocated buffers is in the supplied custom_http_net.c. Anyway, as mentioned, I'll look into it to see if there's some bug in the logic. P.S. Obviously another approach would be to rely on the data maintained locally for taking the decision to allocate/free and use the callback position only to communicate the intention to the HTTP_NET.

2018-8-31 15:39:45 评论举报云达贞