-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing protocolVersion in response header #15
Comments
Thanks for the reminder! I needed to investigate how the HTTP spec said things should work between major versions and it sounds like we just must specify the highest version that we conditionally support, so I've created a config setting and set the default to 1.1. With HTTP/2 here, though, we needed some way for the developer to specify. And I probably need to investigate HTTP/2 in a little bit more detail sometime soon, though from what I've read it doesn't affect the app itself too much, though there's some push-type items that we might be able to provide for. Fixed in e4cdd26 |
It doesn't work that way ... you're reversing the client and server roles - you can't respond with a version higher than the one specified by the client request. It's the client that always requests its own highest supported version. |
Good point, and that's what I was thinking in my head. In CI3 we specify 1.1 explicitly IIRC, And we needed a way to know the highest protocol that our app would support in order to check whether we needed to downgrade, as I understand it. So, I made a config item for the version the application supports so that we can know whether it supports 2 or not. It defaults to 1.1 currently, so you're right we need to check to see if it needs to be downgraded or not. Or do we not even need to worry about that and let the server software handle it? Does that make sense? I've got a massive headache at the moment so not 100% sure :) |
@narfbg Thinking through this a little more, I'm wondering. Does it simply make sense to return the protocol version in the request? It seems that the only thing in our code that HTTP2 would really affect is the ability to do server side push, and this seems to be currently handled via the Link header (at least in NGINX, unsure of others ATM) and those headers would be ignored on HTTP/1.x. So, if the client sends a request for 2 and the server only supports 1.1, it will downgrade it before it gets to us, I believe. Does that sound right? |
2 doesn't bring any changes at the application level, it's all about data transmission - you can't control that anyway. As for 1.1 vs 1.0 ... it doesn't make sense to configure what you support on the server side - you either support 1.1 or you don't. There's no reason to limit yourself to 1.0. |
Have revised to simply send back the requested version, then. Simplifies everything and the rest is not really under the framework's control. Thanks! Fixed in 0333a63 |
We can't see the Welcome page, because the response header is invalid.
We should set protocolVersion somewhere, but I'm not sure where should be.
The text was updated successfully, but these errors were encountered: