在消息主体之前，没有CRLF的解析响应
我有一个使用OKHTTP将请求发送到各种HTTP 1.1服务器的Android应用程序。
它几乎在所有情况下都可以解决问题
，但最终将暂时使用一台服务器，该服务器不会将状态线和消息主体与CRLF线路断开。回顾中间响应，OKHTTP看来将消息主体解释为标题列表。
消息主体将始终以D3 ASCII字符开始。是否可以让Okhttp将其视为响应主体开始的“标头”？
我尝试
使用手动将请求发送到套接字的拦截器，并从插座读取直到收到CRLF或D3（还收集状态线和标题）。但是OKHTTP需要调用链。Proceed（）（复制请求）。
不愉快的解决方案
我的目标是通过电话解决这个问题。如果这是不可能的，看来我唯一的选择是从插座工厂手动获取插座，发送请求并手动解析响应。
真的宁愿不重新发明轮子。任何其他解决方案都将不胜感激。
I have an Android app that uses OkHttp to send Requests to various HTTP 1.1 servers.
The Problem
It works in almost all cases, but will eventually time out for one server that does not separate the status line and message body with a CRLF line break. Reviewing the intermediate response, it appears OkHttp is interpreting the message body as a list of headers.
The message body will always start with a D3 ASCII character. Is it possible to get OkHttp to treat a "header" that starts with this character as the response body?
Tried
I tried using an Interceptor that manually sends the request to the socket and reads from the socket until CRLF or D3 is received (also collecting the StatusLine and headers). But OkHttp requires Chain.proceed() to be called (which duplicates the request).
Unpleasant Solution
My goal is to solve this with a Call. If that is impossible, it appears my only option would be to get a socket manually from the Socket factory, send the request, and manually parse the response.
Really would rather not reinvent the wheel. Any other solutions would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从未找到使用OKHTTP直接修复此操作的方法。值得庆幸的是，它接受了套接字。我要做的是：
（字节）0xD6在前两个CRLF对之前遇到了，则将其替换为CR。然后将LF和D6缓冲或附加到结果上（取决于方法调用）。可悲的是，您不能仅仅覆盖
read（）。read（byte [] b，int off，int len）也被调用（父级实现不调用read（））。这修复了请求结构，允许OKHTTP对其进行解析，因此仍然可以利用该框架，并且不需要直接发送请求。
Never found a way to fix this directly with OkHttp. Thankfully, it accepts a SocketFactory. What I had to do was:
(byte)0xD6is encountered before the first two CRLF pairs, it is replaced by CR. Then LF and D6 are buffered or appended to the result (depending on the method call).You can't sadly just override
read().read(byte[] b, int off, int len)is also called (the parent implementation does not callread()).This fixes the request structure, allowing it to be parsed by OkHttp, so the framework can still be taken advantage of and the request does not need to be sent directly.