aiohttp may respond to requests sent after the client asks for the connection to be closed about aiohttp HOT 4 CLOSED

As we use llhttp, if you convince Node.js to change behaviour, then we'll update the Python parser to match. But, it'd be weird to have different behaviour depending on the parser used.

Given that the client in this case has violated the HTTP protocol, I don't think it really matters whether the behaviour is intuitive or not, it should never be encountered by an HTTP client.

from aiohttp.

That error is from the Python parser. With llhttp, you get the more accurate: Data after Connection: close:.

from aiohttp.

A client that sends a "close" connection option MUST NOT send further requests on that connection (after the one containing the "close")
https://www.rfc-editor.org/rfc/rfc9112#section-9.6-5

For the server, it merely says that it should not process further requests. It does not say it should process the previous request. So, I think tweaking the Python parser to match the llhttp error is fine.

from aiohttp.

For the server, it merely says that it should not process further requests. It does not say it should process the previous request.

I suppose this might be technically allowable, but it's pretty unintuitive in my opinion. I would assume that data received after a connection has been declared closed should not invalidate previous valid messages sent on that connection.

I've since tested this on many more HTTP implementations.

These ones reject the second request without responding to the first:

• Hypercorn
• Node.js

These ones respond to the first request and ignore the second because the connection is closed:
(Mongoose and Uvicorn have changed sides on this because of reports that I submitted, so feel free to ignore those two)

• Apache httpd
• Cheroot
• cpp-httplib
• Dart stdlib
• FastHTTP
• Eclipse GlassFish
• Go net/http
• Gunicorn
• H2O
• HAProxy
• Hyper
• Microsoft IIS
• JetBrains Ktor
• Eclipse Jetty
• Libevent
• Libmicrohttpd
• Libsoup
• Lighttpd
• Mongoose
• Netty
• Nginx
• OpenBSD httpd
• OpenLiteSpeed
• Phusion Passenger
• PHP stdlib
• protocol-http1
• Puma
• Apple ServiceTalk
• Apache Tomcat
• Tornado
• Twisted
• OpenWrt uhttpd
• Unicorn
• Uvicorn
• Waitress
• WEBrick
• Akamai GHost
• Apache Traffic Server
• AWS Application Load Balancer
• AWS Classic Load Balancer
• Cloudflare
• Google Classic Application Load Balancer
• Envoy
• OpenBSD relayd
• Pingora
• Pound
• Squid
• Varnish

Given the behavior of other implementations, it's probably worth at least documenting that AIOHTTP handles things differently.

from aiohttp.