[erlang-bugs] Too strict HTTP Status Line parsing

Alexander Zhuravlev <>
Wed Jun 2 21:30:45 CEST 2010


On Wed, Jun 2, 2010 at 14:09, Sverker Eriksson <> wrote:
> Alexander Zhuravlev wrote:
>>
>> Hello,
>>
>> I've tried to use lhttpc library (http://bitbucket.org/etc/lhttpc) to
>> fetch
>> a resource (http://www.qype.com/review/1376848) and got the following
>> error:
>>
>> {{http_error,"HTTP/1.1 200\r\n"},
>>        [{lhttpc_client,read_response,5},
>>        {lhttpc_client,execute,8},
>>        {lhttpc_client,request,9}]}
>> I've checked lhttpc source code and found out that to receive and parse an
>> HTTP
>> response it uses _standard_ erlang module gen_tcp on a socket in
>> {packet, http} mode. So it looks like the {http_error,"HTTP/1.1 200\r\n"}
>> error was
>> in fact generated by erlang's http packet parsing code.
>>
>> I found the following code in packet_parse_http function from
>> erts/emulator/beam/packet_parser.c file:
>>
>> ...
>> p0 = ptr;
>> while (n && SP(ptr)) {
>>        ptr++; n--;
>> }
>> if (ptr==p0) return -1;
>> ...
>>
>>
>
> A change to
>
> if (ptr==p0 && n>0) return -1;
>
> would do it, right?

Yes, probably. But I suppose that fact that the string does not have a
phrase string may cause
other issues with this call in the packet_parse_http function:

return pcb->http_response(arg, major, minor, status,
                                      ptr, n);

ptr will point to the end of the string and n will be equal to 0.

>
> /Sverker, Erlang/OTP
>
>> As far as I understand "HTTP/1.1 200\r\n" line does not have any spaces
>> after the status code "200", and the function strips \r\n as a first step
>> of
>> its operation. So the "while" cycle does not run and we get into the
>> "if (ptr==p0) branch" this basically leads to returning of {http_error,
>> "HTTP/1.1 200\r\n"} atom up to the call stack.
>>
>> Strictly speaking this is not a bug in erlang, but I suppose it
>> should take a more relaxed approach to HTTP Status Line parsing
>> and not return http_error if an HTTP response Status Line does not have
>> a Reason-phrase part.
>>
>> ________________________________________________________________
>> erlang-bugs (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:
>>
>>
>
>



-- 
Alexander Zhuravlev


More information about the erlang-bugs mailing list