Sebastian Beltran
Sebastian Beltran
I'm fine with removing support for older Node versions in this package, but I don't think that should go in this PR
I guess we shouldn't do anything in this case, right? https://github.com/jshttp/on-headers/pull/16#issuecomment-2627449045
Yep, that's why my philosophical doubt. So for now, no error, maybe it's good that Node.js throws the error.
So far, we have been using the HTTP/1 compatibility layer provided by Node.js, but I'm going to look into running tests outside of that compatibility layer
This works great with the compatibility layer, but it doesn't work with http2Session
For compression, we need to modify the headers, which is quite easy with HTTP/1, but with HTTP/2 and without the compatibility layer, it gets complicated, since headers are only sent...
It would be better if the new pages were translated in different PRs, as it could happen like in https://expressjs.com/ru/resources/applications.html where the page is not translated into the corresponding language.
Is it useful to bring in the boilerplate when Express@5 is almost ready? If it's for historical purposes, it might be better to handle it, for example, with a URL...
Another option would be to route deprecated APIs through subdomains, as I suggest in #1556
After a long time since this PR was created,I'm not in favor of adding these resources to the page, for several of the reasons @crandmck mentioned. Also, there are middlewares...