hackney icon indicating copy to clipboard operation
hackney copied to clipboard

HTTP inform not supported

Open Gazler opened this issue 4 years ago • 3 comments

After using hackney with cowboy, it appears that inform responses are not supported, and that hackney is awaiting further data even though the response has been sent.

A sample repository using cowboy is available at https://github.com/Gazler/inform_test

For the same server, using another client such as gun or curl returns immediately, however hackney doesn't return until the idle/request timeout is triggered on cowboy.

@essen may be able to give more details since he helped investigate this bug.

Gazler avatar May 29 '20 21:05 Gazler

You can run this in the shell to see what hackney is doing:

dbg:tracer().
{ok, Mods} = application:get_key(hackney, modules),
[dbg:tpl(M, []) || M <- Mods],
dbg:p(all, c).
inform_test:request().

But it's quite simple really, it sees the 103 response, checks for transfer-encoding or content-length, doesn't find any (no such thing for 1xx) and switch to reading the body until the end of the connection.

essen avatar May 30 '20 06:05 essen

So I was reading the Early Hints https://tools.ietf.org/html/rfc8297 RFC to see how to handle 103. I can't simply ignore it as I expected, instead I need to ready headers, return and continue the request similarly to the 101 status.

I will add support for it ASAP.

benoitc avatar Jun 01 '20 10:06 benoitc

I mean if you want to support it you can't ignore it of course. :-) But you should either ignore unknown 1xx status codes OR handle them all including ones that aren't released yet. It's informational so it's up to the client to choose how to behave. In Gun all 1xx status codes produce a gun_inform message, and there's special code for switching protocols via 101, if the Upgrade header was in the request.

essen avatar Jun 01 '20 12:06 essen