[erlang-bugs] Fwd: Inets(5.5.1) http client keep alive mode doesn't follow RFC2616

caox <>
Wed Nov 16 10:31:56 CET 2011


	Have this bug been fixed in the latest version?



> 发件人: caox <>
> 日期: 2011年8月16日 下午05时45分27秒格林尼治标准时间+0800
> 收件人: Ingela Anderton Andin <>
> 抄送: Micael Karlberg <>
> 主题: 回复: Inets(5.5.1) http client keep alive mode doesn't follow RFC2616
> Thanks.
> 在 2011-8-16,下午5:28, Ingela Anderton Andin 写道:
>> Hi!
>> Well it looks like a bug to me, probably a slip up during a refactoring
>> of the code.
>> I have created a ticket for it to be solved for the next release.
>> Regards Ingela Erlang/OTP team - Ericsson AB
>> caox wrote:
>>> Sorry to bother you. But I have some questions of inets http client as
>>> below. And I found you in the author list of inets so I sent this to you.
>>> 下面是被转发的邮件:
>>>> *发件人: *caox < <mailto:>>
>>>> *日期: *2011年8月14日上午11时32分57秒格林尼治标准时间+0800
>>>> *收件人: * <mailto:>
>>>> *主题: **Inets(5.5.1) http client keep alive mode doesn't follow RFC2616*
>>>> Hi
>>>> According to RFC2616, a HTTP/1.1 client should send a request and
>>>> then wait for the response before sending any subsequent request on a
>>>> persistent connection if without pipelining.
>>>> But when using inets5.5.1 of R14B01, we found httpc send requests
>>>> directly to the connection without checking whether the earlier
>>>> request on it has been responded. According to the TCP packets we
>>>> captured from web communication, several requests were passed on the
>>>> same connection in one TCP packet and it seems worked in pipelining
>>>> mode. And we use the default inets opiton setting so the pipelining
>>>> should be off in the situation.
>>>> Also, we follow the source code of inets implementation and do not
>>>> find any significant difference between keep alive and pipelining in
>>>> the sending mechanism. In both mode httpc_manager:handle_request call
>>>> httpc_handler:send, and in httpc_handler:send pipelining and keep
>>>> alive requests will be queued in different queue in the process state
>>>> and then sent to current connection of handler by httpc_request:send
>>>> and then httpc_transport:send.
>>>> So,it is a bug, or there is something I have missed in the source code?
>>>> BR

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20111116/3dfb990e/attachment.html>

More information about the erlang-bugs mailing list