OleMchls/elixir-hpack

Match error on decoding HTTP/2 response headers

Closed this issue · 10 comments

lucacorti commented 
23:05:14.467 [debug] RECVD DATA
<<0, 0, 108, 1, 4, 0, 0, 0, 1, 136, 118, 137, 170, 99, 85, 229, 128, 174, 16, 46, 31, 97, 150, 220, 52, 253, 40, 7, 212, 203, 109, 10, 8, 1, 113, 65,
6, 224, 25, 184, 219, 234, 98, 209, 191, 95, 135, 73, 124, 165, ...>>

23:05:14.483 [error] GenServer #PID<0.162.0> terminating
** (MatchError) no match of right hand side value: <<176, 52, 200, 218, 88, 78, 53, 252, 255, 0, 137, 25, 8, 90, 210, 181, 131, 170, 98, 163, 132, 143
, 210, 74, 143>>
    lib/hpack.ex:212: HPack.parse_string/1
    lib/hpack.ex:123: HPack.parse/3
    ...
OleMchls commented

Could you provide some more information, like a failing test or some code to reproduce?

lucacorti commented

It seems this fails trying to decode headers for a 200 OK response from my server (nginx/1.10.1).
When the server returns 400 Bad Request decoding succeeds.

I'll try to provide some working code demostrating this over the weekend.

lucacorti commented

Apparently, I was feeding HPack.decode/2 something wrong. After cleaning up header block fragment handling code the issue disappeared.

Sorry for the noise, and thank you.

OleMchls commented

glad to hear you figured it out :)

lucacorti commented

I think I found something. I'm trying a request against my own server, and header decoding fails. I've debugged the code and am pretty confident I'm not doing anything stupid.

** (MatchError) no match of right hand side value: <<247, 228, 145, 246, 86, 19, 141, 127, 63, 0, 137, 25, 8, 90, 210, 181, 131, 170, 98, 163, 132
, 143, 210, 74, 143>>
    lib/hpack.ex:212: HPack.parse_string/1
    lib/hpack.ex:123: HPack.parse/3

To reproduce you can checkout https://github.com/lucacorti/http2 and then:

$ mix deps.get
$ iex -S mix
iex(1)> Http2.Client.get("https://www.fantacast.it")
OleMchls commented

Hello Luca,

could you distill the case you just found into a failing test? Or a HBF that fails to decode, as far as I could judge from the code you posed its some non-Huffman encoded string that fails to decode. But again having a case to reproduce this quickly would be great.

Also I'd like to invite you to poke around this code and send a PR, I'd happily answer any starter questions you have.

cheers

lucacorti commented

See #3

OleMchls commented

fixed with 4dc265d

OleMchls commented

just released 1.0.2 including the bugfix

OleMchls commented

I also would like to take the opportunity to say a HUGE thank you @lucacorti for your help ✨

  • ❤️1