Open Gazler opened 4 years ago
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.
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.
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.
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.