HTTP long polling is just a buzzword for opening an HTTP connection to a web server, and keeping it open in order to repeatedly receive chunks of data. This was a workaround for web browsers that did not support Web Sockets or Server-sent events and did not have a mechanism to do real-time updates using streaming data.
Think of Web Sockets and server-sent events in a browser as the client side compliment to traditional message brokers like RabbitMQ and Kafka.
I remember implementing this once about 10 years ago. I don't remember that we needed to configure the web server any different. HTTP long polling is not a feature of a web server. It basically means "obscenely long inactivity timeout for both server and client."
Since the client initiates any kind of connection to the web server, the client is also responsible for closing the socket connection. I imagine both client and web server need to be configured to allow open connections with no activity for an extended period of time. I think we settled on 1 minute.
Since I last implemented HTTP long polling, modern browsers support Web Sockets and server-sent events. Prefer web sockets if you need bi-directional communication or to transmit binary data. Server sent events are preferred for things like push notifications, where transmitting data in text is all you need, and the client does not need to send data back to the server.