CherryPy is a pythonic, object-oriented HTTP framework. | post your issues to: github.com/cherrypy/cherrypy/issues | FAQ: https://stackoverflow.com/questions/tagged/cheroot+or+cherrypy
some things that are under server: https://github.com/cherrypy/cherrypy/blob/2cc6da312556c1f4a53677a88f02bee5e2221cbd/cherrypy/_cpserver.py#L14
And I do think tests like "no_CRLF" would actually be beneficial there in h11, not sure what their existing tests look like at the moment though!
AFAIR the RFC says something like you should use CR LF but if the other end just uses LF, server can also gracefully parse that.
@sathishbabu96 basically the docs tell you to look at the corresponding classes: https://docs.cherrypy.org/en/latest/config.html#builtin-namespaces
So do you think that test should be declared invalid? Or modified?
@duper51 hmm, I think currently h11 does insist on getting CRLF exactly as terminators, which is what the standard says to do. Possibly it just doesn't notice the problem as promptly as your test expects, because it's still waiting for \r\n\r\n before trying to parse the headers?
(also we need to fix h11 to accept bare LF as a terminator, because despite what the standards say, folks expect this to work in practice. but that's a separate issue.)
h11's strategy is to slurp up data until it sees the \r\n\r\n at the end of the headers and then parse all the headers in one swoop, which is substantially simpler and faster than parsing headers one at a time as they arrive on the wire. but it does mean that if we get some kind of invalid data in the headers, we won't notice until after we see an \r\n\r\n
Or set to expect a timeout
so h11 will probably treat the
\r as optional in general, rather than specifically disallowing \r\n\n
oh heh, though that request in the test is invalid anyway, because it says HTTP/1.1 but doesn't have a host header :-)
seriously, I don't think that test is very important. it's kind of testing a detail of cherrypy's old parser, and there's an argument that you don't need to be testing these kinds of details at all since h11 has its own test suite now :-). IMO tweaking it to expect a timeout would be reasonable, tweaking it to check for other kinds of invalid header characters would be reasonable (e.g. NULs or a header like
Hi: foo\rbar), removing it entirely would be reasonable...
@duper51 cherrypy/cherrypy#1837 is invalid on our side, it's piwheels' fault, we cannot do anything about it — they should implement PEP503
Now I have an existing app which always used port 1234 and was basically always the root serving at '/'. I did now find a way with hostmap to tell cherrypy to use the same ip with port 8080 and also use root serving at '/'. Anyone has an idea about a workaround?
File an issue if that's the case. It'd be great if you could submit a PR with a reproducer test marked as xfail as per https://pganssle-talks.github.io/xfail-lightning.
@MikHulk they are not that compatible
@webknjaz ok, I have read this on the wikipedia article https://en.wikipedia.org/wiki/HTTP/2. I am not specialist so I believe you.
I am learning about upper version
where's the test?
I believe I fixed the issue. It had to do with not specifying the specific number of bytes I intended to receive. The bytes were present in the byte buffer, but since they weren't terminated by anything, it appears that the python BufferedReader implementation doesn't read those bytes and instead makes a call to the parent receive which times out.
In other news, how reliable are the SSL tests supposed to be? I'm having intermittent failures on several of these with massive stack traces, but as far as I can tell it's not the new additions. Is this common in the current iteration of the project?
@duper51 TLS tests are relatively fine in the CI but under some envs there's flaky behavior. This is related to the combination of the Python version, SSL adapter chosen (stdlib
We should keep them green in the CIs, the only case I saw unstable in CIs is
ssl module or pyOpenSSL) and the backend implementation and version (openssl 0.9/1.0/1.1, libressl etc.). All of these have slightly different behaviors and it's hard to figure out what to check in each env sometimes.We should keep them green in the CIs, the only case I saw unstable in CIs is
test_http_over_https_error under GH Actions + Python 2.7 + Windows. Others usually don't fail because the tests cover most of the weird behaviors. This is something that needs to be addressed separately. But I think I'll just wait until Python 2 is dropped and they won't be a problem then.