Skip to content

Conversation

@bjohansebas
Copy link
Member

Support for HTTP/2 is added as part of supporting HTTP/2 in compression and in the future, in express

@bjohansebas bjohansebas force-pushed the http2 branch 4 times, most recently from 9da16ff to 614b831 Compare January 31, 2025 02:00
@bjohansebas
Copy link
Member Author

Currently, there is a test that, although it is not failing, is still showing a warning in Node.js. I will need to investigate the best way to proceed

image

@bjohansebas
Copy link
Member Author

@jshttp/express-tc given that writeHead can receive a string as the second parameter, which is not supported in HTTP/2, should we throw an error?

@wesleytodd
Copy link
Member

I can look through this in more detail, but I wanted to first ask if we should just drop node versions so we can remove the try/catch on require('http2)?

@bjohansebas
Copy link
Member Author

I'm fine with removing support for older Node versions in this package, but I don't think that should go in this PR

@bjohansebas
Copy link
Member Author

I guess we shouldn't do anything in this case, right?
#16 (comment)

@wesleytodd
Copy link
Member

I mean that is coming from the tests here right? I didn't really dig into that, but I am not sure throwing an error is desirable if node is treating it as a warning.

@bjohansebas
Copy link
Member Author

Yep, that's why my philosophical doubt. So for now, no error, maybe it's good that Node.js throws the error.

@bjohansebas
Copy link
Member Author

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

@bjohansebas
Copy link
Member Author

This works great with the compatibility layer, but it doesn't work with http2Session

@bjohansebas bjohansebas marked this pull request as draft May 19, 2025 00:13
Signed-off-by: Sebastian Beltran <[email protected]>
Signed-off-by: Sebastian Beltran <[email protected]>
@bjohansebas
Copy link
Member Author

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 once. That means we can't modify them afterward, so we'd need to find a way to ensure that if there's a stream.respond, it's the only one sent and includes the headers we plan to send, without using this package

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants