[erlang-questions] httpc streaming bodies of 404 responses

Ingela Andin ingela@REDACTED
Fri Jan 13 22:47:45 CET 2012


Hoops now for the list too....


---------- Forwarded message ----------
From: Ingela Andin <ingela.andin@REDACTED>
Date: 2012/1/13
Subject: Re: [erlang-questions] httpc streaming bodies of 404 responses
To: Shane Evans <shane.evans@REDACTED>


Hi!

Thank you for reporting this again, it must alas have been missed by us.
We will fix it removing the clause so it works as expected.

Regards Ingela Erlang/OTP team - Ericsson AB

2012/1/13, Shane Evans <shane.evans@REDACTED>:
> Hi,
>
> This has been raised before:
> http://erlang.org/pipermail/erlang-questions/2010-February/049267.html
> But I didn't see any replies.
>
> I am using the http options {sync, false} and {stream, self} with
> httpc:request/4. The documentation of stream says:
>
>> Streams the body of a 200 or 206 response to the calling process or to
>> a file. When streaming to the calling process using the option self
>> the following stream messages will be sent to that process: {http,
>> {RequestId, stream_start, Headers}, {http, {RequestId, stream,
>> BinBodyPart}, {http, {RequestId, stream_end, Headers}.
> However, when a server replies with a 404 status, I get a message of the
> form:
> {request_id() ,  {status_line(), headers(), Body}}
> as expected, but Body is empty (<<>>) and then the actual body of the
> response is sent as a stream message:
> {http, {request_id(), stream, Body}}
> note that there was no stream_start or stream_end messages.
>
> This seems like a bug to me... but if you look at http_handler:stream, there
> is clearly a function clause doing exactly this when status is 404.  I guess
> my question is why? and would it be a good idea to either document this, or
> remove that function clause (in which case 404s would be handled as you'd
> expect)?
>
> Thanks,
>
> Shane
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list