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 fastify/fastify-http-proxy#253.

Checklist

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

[simoneb]

Nice job. This change LGTM, but I'd like to wait for somebody else's review before merging.

[gurgunday]

Makes sense, lgtm

[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 (fastify/fastify-http-proxy#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?