You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A server that receives a "close" connection option MUST initiate closure of the connection (see below) after it sends the final response to the request that contained the "close" connection option. The server SHOULD send a "close" connection option in its final response on that connection. The server MUST NOT process any further requests received on that connection.
When aiohttp receives a pipeline with a request containing Connection: close, followed by an invalid request, aiohttp responds only to the second (invalid) request, even though the standard requires that aiohttp respond only to the first one.
Observe that the only response received is intended for the invalid request:
HTTP/1.0 400 Bad Request
Content-Type: text/plain; charset=utf-8
Content-Length: 25
Date: Mon, 29 Jan 2024 03:20:29 GMT
Server: Python/3.11 aiohttp/4.0.0a2.dev0
Bad status line 'Invalid'
Expected behavior
The server should respond only to the first request, and then close the connection.
Logs/tracebacks
Error handling request
Traceback (most recent call last):
File "/app/aiohttp/env/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 366, in data_received
messages, upgraded, tail =self._request_parser.feed_data(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/aiohttp/env/lib/python3.11/site-packages/aiohttp/http_parser.py", line 325, in feed_data
msg: _MsgT =self.parse_message(self._lines)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/aiohttp/env/lib/python3.11/site-packages/aiohttp/http_parser.py", line 558, in parse_messageraise BadStatusLine(line) fromNoneaiohttp.http_exceptions.BadStatusLine: 400, message:
Bad status line 'Invalid'
$ python -m pip show multidictName: multidictVersion: 6.0.4Summary: multidict implementationHome-page: https://github.com/aio-libs/multidictAuthor: Andrew SvetlovAuthor-email: andrew.svetlov@gmail.comLicense: Apache 2Location: /app/aiohttp/env/lib/python3.11/site-packagesRequires:Required-by: aiohttp, yarl
yarl Version
$ python -m pip show yarlName: yarlVersion: 1.9.4Summary: Yet another URL libraryHome-page: https://github.com/aio-libs/yarlAuthor: Andrew SvetlovAuthor-email: andrew.svetlov@gmail.comLicense: Apache-2.0Location: /app/aiohttp/env/lib/python3.11/site-packagesRequires: idna, multidictRequired-by: aiohttp
OS
Debian 12 (running in Docker on Arch Linux)
Linux 6.7.2
Related component
Server
Additional context
Some other HTTP implementations that handle this correctly:
Apache httpd, Boost::Beast, Daphne, H2O, Lighttpd, Nginx, Tornado, OpenWrt uhttpd, Waitress
Some other HTTP implementations that also have this bug:
Mongoose, Uvicorn
Code of Conduct
I agree to follow the aio-libs Code of Conduct
The text was updated successfully, but these errors were encountered:
kenballus
changed the title
aiohttp prematurely terminates some connections when Connection: close is present
aiohttp may respond to requests sent after the client requests for the connection to be closed
Jan 29, 2024
kenballus
changed the title
aiohttp may respond to requests sent after the client requests for the connection to be closed
aiohttp may respond to requests sent after the client asks for the connection to be closed
Jan 29, 2024
Describe the bug
From RFC 9112, section 9.6:
When aiohttp receives a pipeline with a request containing
Connection: close
, followed by an invalid request, aiohttp responds only to the second (invalid) request, even though the standard requires that aiohttp respond only to the first one.To Reproduce
Connection: close
set, followed by an invalid request:Expected behavior
The server should respond only to the first request, and then close the connection.
Logs/tracebacks
Python Version
aiohttp Version
multidict Version
yarl Version
OS
Debian 12 (running in Docker on Arch Linux)
Linux 6.7.2
Related component
Server
Additional context
Some other HTTP implementations that handle this correctly:
Apache httpd, Boost::Beast, Daphne, H2O, Lighttpd, Nginx, Tornado, OpenWrt uhttpd, Waitress
Some other HTTP implementations that also have this bug:
Mongoose, Uvicorn
Code of Conduct
The text was updated successfully, but these errors were encountered: