HTTP 分块传输编码和 MFC
我有一个用 MFC 编写的专有客户端-服务器应用程序。除了我的客户端之外，没有其他客户端会与服务器进行通信。出于安全原因，我们使用 HTTP。
在know之前，我们使用content-length来描述客户端响应主体结束的地方。现在我们遇到的情况是事先不知道长度并且无法缓冲数据。我在 rfc 中读到有分块传输编码。问题是我不想实现 rfc(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6第3.6.1节）。
问题是，如果我使用自己的块格式，然后 MFC 类尝试解析它，它将出错，因为这不是 RFC 中定义的预期格式。
是否可以将“分块传输编码”放入响应标头中，然后使用我自己的块格式？或者换句话说，MFC 类在响应标头中看到“分块传输编码”时，是否会尝试根据 rfc 中更改格式的定义来解析正文？
I have a Proprietery Client-Server application written in MFC. No clients other then my client is going to communicate with the server . For safetly reason , we are using HTTP.
Until know , we used content-length to describe the client where the response body ends. Now we are having a situation where the length isn't known in advance and we can't buffer the data. I read in the rfc that there is the Chunked Transfer Coding. The problem is that I don't want to implement the formatting which is defined in the rfc(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6 section 3.6.1).
The problem is that if I use my own chunk formatting and then MFC class try to parse it , it will through error since this is not the format is expect as defined in the RFC.
Is it possible to put "Chunked Transfer Coding" in the response headers and then use my own chunk formatting? Or in other words , does MFC classes , when they see "Chunked Transfer Coding" in the response headers , try to parse the body according to the defintion of chanked formatting in the rfc ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定我是否理解。
1) RFC 2616 定义的分块编码有什么问题？
2）现有代码应该如何处理它不知道的编码？
I'm not sure I understand.
1) What's wrong with the chunked encoding as defined by RFC 2616?
2) And how is existing code supposed to deal with an encoding it doesn't know?