fix: DELETE requests should not call stream.end

[karl-power]

It appears that DELETE streams behave the same as GET streams in that they are not writable (immediately ended?), so calling .end on the stream throws a write after end error (related issue).

I cannot find this documented anywhere in HTTP2 spec or in NodeJS HTTP2 module (aside from the endStream header, and http2stream.endAfterHeaders which don't seem to affect anything here - can anyone share insight?).

This PR simply adds the DELETE method to a check on whether or not to end the stream. The change fixes https://github.com/fastify/fastify-http-proxy/issues/253.

Checklist

• [x] run npm run test and npm run benchmark
• [x] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [x] commit message and code follows the Developer's Certification of Origin and the Code of conduct

[gurgunday]

It appears that DELETE streams behave the same as GET streams in that they are not writable (immediately ended?), so calling .end on the stream throws a write after end error (https://github.com/fastify/fastify-http-proxy/issues/253).

Yeah I thought for the same reasons when approving, that DELETE requests are like GET requests, but I just learned that they actually might have a body, so they can be writable (?) – maybe for all practical purposes it is interpreted the same way

Not 100% sure if this is the reason or not

[karl-power]

Hi @mcollina & @climba03003 Any idea if this is the right approach here?