You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would you be receptive to me adding Hypercorn as a test server (alongside Uvicorn)? I think for this project it would be good to test HTTP/2 against a production server. Whilst for Hypercorn it would be great to know that it doesn't upset this client.
Hmm... Sorry that my previous message didn’t sound as excited as I am about this idea!
If you want to put together a PR demonstrating the idea it would be great, no need to wait for the refactor I mentioned to be done — you may have to deal with conflicts, but that’s about it. Thanks for suggesting this!
It's possible that I've been overzealous wrt. "it'd be easier to manage for encode if we're using an encode server". I'm wondering if there's actually blockers there, of if that's just me being closed-minded.
Would there be any issues wrt. differing supported Python versions that could make this problematic for us?
If we did want to do this, I'd rather we just switched away from uvicorn completely.
I guess if possible it might be sensible for the majority of tests to just run against a server instance that's setup in a seperate thread and that is available throughout the entire test suite lifetime. (?)
a server instance that's setup in a seperate thread and that is available throughout the entire test suite lifetime
FWIW that's already what we've got — up to 4 servers, i.e. one for {HTTP, HTTPS} x {TCP, UDS}, running in their own thread and available throughout the test session. (We might be able to reduce to 2 by having servers support both HTTP and HTTPS, though?)
Hey, so I'm going to proactively close this as time has sort of proven that we're at least good enough with the current setup. Sure, it'd be nice to have a local HTTP/2 server to test against, but I'm not sure we'd actually catch more bugs just by having that vs by testing more cases (eg replicating #514). So… Closing for housekeeping. :-)
Activity
florimondmanca commentedon Aug 28, 2019
We might benefit from this in #276 as well.
Let’s first refactor the current server setup as mentioned in #276 (comment), and then perhaps consider this?
pgjones commentedon Aug 28, 2019
ok, sounds good.
florimondmanca commentedon Aug 28, 2019
Hmm... Sorry that my previous message didn’t sound as excited as I am about this idea!
If you want to put together a PR demonstrating the idea it would be great, no need to wait for the refactor I mentioned to be done — you may have to deal with conflicts, but that’s about it. Thanks for suggesting this!
florimondmanca commentedon Aug 29, 2019
@pgjones FYI, the test server refactoring I mentioned earlier is in. 👍
lovelydinosaur commentedon Sep 2, 2019
If we're able to run the tests against both hypercorn & uvicorn, then that seems like it might be a nice bit of progress yeah.
lovelydinosaur commentedon Dec 21, 2019
It's possible that I've been overzealous wrt. "it'd be easier to manage for
encodeif we're using anencodeserver". I'm wondering if there's actually blockers there, of if that's just me being closed-minded.florimondmanca commentedon Dec 21, 2019
FWIW that's already what we've got — up to 4 servers, i.e. one for {HTTP, HTTPS} x {TCP, UDS}, running in their own thread and available throughout the test
session. (We might be able to reduce to 2 by having servers support both HTTP and HTTPS, though?)pgjones commentedon Jan 4, 2020
If you do wish to use Hypercorn you can have a single instance serve HTTP, HTTPS, TCP, UDP, h11, h2, h3 at once.
lovelydinosaur commentedon Jan 6, 2020
@pgjones Good to know, thanks.
I guess the main criteria we'd want for figuring if this'd be a good idea would be:
florimondmanca commentedon Mar 13, 2020
Hey, so I'm going to proactively close this as time has sort of proven that we're at least good enough with the current setup. Sure, it'd be nice to have a local HTTP/2 server to test against, but I'm not sure we'd actually catch more bugs just by having that vs by testing more cases (eg replicating #514). So… Closing for housekeeping. :-)