too many header bytes seen; overflow detected

[SG87]

🐞 Describe the bug
When sending a call in a aiohttp ClientSession, the error too many header bytes seen; overflow detected is returned.

💡 To Reproduce
No exact code to reproduce, because it uses proprietary sources. The code:

import asyncio
import aiohttp

loop = asyncio.get_event_loop()

url = "https://url.com"
bodies = [{"body": 1}, {"body": 2}, {"body": 3}]

async def request(body, session):
    async with session.post(url, json=body) as resp:
        return await resp.json()
    #return await es_client.search(index=es_index, doc_type=es_doc_type, body=query)

async def msearch(bodies):
    async with aiohttp.ClientSession() as session:
        tasks = [asyncio.ensure_future(request(body, session)) for body in bodies]
        return await asyncio.gather(*tasks)

results = loop.run_until_complete(msearch(bodies))

💡 Expected behavior
This code should return a json response.

It is working for most calls, but if the result?/header?/...? of a call is getting to big, this message is thrown?

📋 Logs/tracebacks

Traceback (most recent call last):
  File "/Users/stijngeuens/.virtualenvs/findme/lib/python3.7/site-packages/aiohttp/client_reqrep.py", line 847, in start
    message, payload = await self._protocol.read()  # type: ignore  # noqa
  File "/Users/stijngeuens/.virtualenvs/findme/lib/python3.7/site-packages/aiohttp/streams.py", line 591, in read
    await self._waiter
  File "/Users/stijngeuens/.virtualenvs/findme/lib/python3.7/site-packages/aiohttp/client_proto.py", line 201, in data_received
    messages, upgraded, tail = self._parser.feed_data(data)
  File "aiohttp/_http_parser.pyx", line 523, in aiohttp._http_parser.HttpParser.feed_data
aiohttp.http_exceptions.BadHttpMessage: 400, message='too many header bytes seen; overflow detected'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/Users/stijngeuens/.pyenv/versions/3.7.3/lib/python3.7/site-packages/IPython/core/interactiveshell.py", line 3326, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-25-8dd725416572>", line 11, in <module>
    results = loop.run_until_complete(msearch(bodies))
  File "/Users/stijngeuens/.pyenv/versions/3.7.3/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
    return future.result()
  File "<ipython-input-25-8dd725416572>", line 9, in msearch
    return await asyncio.gather(*tasks)
  File "<ipython-input-25-8dd725416572>", line 2, in request
    async with session.post(url, json=body) as resp:
  File "/Users/stijngeuens/.virtualenvs/findme/lib/python3.7/site-packages/aiohttp/client.py", line 1012, in __aenter__
    self._resp = await self._coro
  File "/Users/stijngeuens/.virtualenvs/findme/lib/python3.7/site-packages/aiohttp/client.py", line 504, in _request
    await resp.start(conn)
  File "/Users/stijngeuens/.virtualenvs/findme/lib/python3.7/site-packages/aiohttp/client_reqrep.py", line 852, in start
    message=exc.message, headers=exc.headers) from exc
aiohttp.client_exceptions.ClientResponseError: 400, message='too many header bytes seen; overflow detected', url=URL('https://url.com')

📋 Your version of the Python

Python 3.7.3 (default, Oct 18 2019, 10:37:04) 

📋 Your version of the aiohttp/yarl/multidict distributions

aiohttp==3.6.2
yarl==1.3.0
multidict==4.5.2

📋 Additional context
Running on Mac OS. Error both in Pycharm and Docker
Call is going to a local ES instance for development
Using the client library (ClientSession)

[webknjaz]

Interestingly, the code search by the error message does not return anything from this repository or even org. I wonder if it's coming from some underlying library...

[webknjaz]

@SG87 I noticed that you use a 1.5-year-old version of aiohttp. Have you checked that it's reproducible in newer versions? We don't do backports so if there's any fix necessary, it'll be released under the 3.8-stream or higher (whenever the patch is invented).

On a side note, just staring at the source hasn't revealed anything suspicious. Somebody will need to stick a debugger there and see what's happening in runtime. Also, it sounds like you verified the issue under *NIX (macOS + GNU/Linux since docker containers run that in a Linux VM on macs).

If you can come up with a reproducer in a form of a pytest-based test, feel free to send a PR with it — merging regression tests is always useful.

[webknjaz]

@anesabml if you want to try debugging this, have fun ;)

[Dreamsorcerer]

Interestingly, the code search by the error message does not return anything from this repository or even org. I wonder if it's coming from some underlying library...

If you mean the 'header bytes' message, it appears to be under a submodule, so maybe you missed it.
https://github.com/nodejs/http-parser/blob/2343fd6b5214b2ded2cdcf76de2bf60903bb90cd/http_parser.h#L255

[Dreamsorcerer]

I guess if the error is coming from there, then the issue should probably be moved to the nodejs project. Although it's unmaintained, so probably no point. Perhaps the issue will be resolved once the parsing library has been changed in aiohttp.

[SG87]

Just upgraded to aiohttp==3.7.4.post0. Still the same error.
Thanks for looking into the issue.

[webknjaz]

I guess if the error is coming from there, then the issue should probably be moved to the nodejs project. Although it's unmaintained, so probably no point. Perhaps the issue will be resolved once the parsing library has been changed in aiohttp.

Fair enough. Blocked by #3561.

[anesabml]

@webknjaz So there's no need to debug this?

[webknjaz]

I guess not anymore.

[SG87]

Any idea when the parsing library changes in aiohttp and this issue might be resolved?

[webknjaz]

When somebody will take time to implement it. It's a volunteer project so it is hard to predict.

[wfatherley]

Is resolving this issue simply just that the header file and sources of the node HTTP parser need to be reworked?

[webknjaz]

@wefatherley Maybe, but that lib is no longer maintained. We need to migrate to https://github.com/nodejs/llhttp instead.

This is tracked at #3561 and there's even a PR #5364 that I haven't had time to check but you're welcome to.