Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 03 18:34
    noonedeadpunk closed #1847
  • Apr 03 18:27
    noonedeadpunk opened #1847
  • Apr 03 16:57
    webknjaz closed #1843
  • Apr 03 16:50

    webknjaz on master

    Add a config for YAMLlint Stop requiring unreleased pyyam… Advise users to install pre-com… and 1 more (compare)

  • Apr 03 16:43

    webknjaz on master

    Add noop .zuul.yaml file for zu… Merge pull request #1846 from v… (compare)

  • Apr 03 16:43
    webknjaz closed #1846
  • Apr 02 17:23
    noonedeadpunk edited #1846
  • Apr 02 17:23
    noonedeadpunk edited #1846
  • Apr 02 17:23
    codecov[bot] commented #1846
  • Apr 02 17:23
    noonedeadpunk synchronize #1846
  • Apr 02 17:03
    noonedeadpunk synchronize #1846
  • Apr 02 17:02
    noonedeadpunk opened #1846
  • Mar 14 17:14
    codecov[bot] commented #1760
  • Mar 14 04:36
    ygbr edited #1767
  • Mar 14 04:35
    ygbr edited #1767
  • Mar 02 21:42
    benjaoming edited #1845
  • Mar 02 21:39
    triage-new-issues[bot] labeled #1845
  • Mar 02 21:39
    benjaoming opened #1845
  • Feb 28 13:05
    zarinpy edited #1843
  • Feb 28 13:05
    zarinpy edited #1843
Ian Otto
@duper51

That said, I'm having an issue where H11 doesn't seem to be marking a connection as invalid when we get invalid terminators, which causes the connection to timeout (see test_No_CRLF in test_conn.py)

^ this is still valid btw

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!
Sviatoslav Sydorenko
@webknjaz
yeah, it may be worth contributing them to h11
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
Ian Otto
@duper51
@webknjaz See #1837, I believe this is valid
So do you think that test should be declared invalid? Or modified?
Nathaniel J. Smith
@njsmith
@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.)
Ian Otto
@duper51
Yeah the test just dies on an HTTP timeout, which I suppose might be also acceptable behavior for the server only receiving "\r\n\n", etc.
Nathaniel J. Smith
@njsmith
yeah, that makes sense, and it's an interesting side-effect of h11's parsing strategy; I hadn't thought about that before
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
Ian Otto
@duper51
Hmm... Perhaps the test should be modified so that there is more data to test...
Or set to expect a timeout
Nathaniel J. Smith
@njsmith
or I guess fix h11 to accept \n\n, and change the test to expect it to work :-)
Ian Otto
@duper51
The test does send a combination of the two line-endings at the moment, so it'd be invalid either way I believe!
Nathaniel J. Smith
@njsmith
I've seen a mix of \r\n and \n as terminators in the same HTTP headers in the wild
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 :-)
Nathaniel J. Smith
@njsmith
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...
Sviatoslav Sydorenko
@webknjaz
@duper51 cherrypy/cherrypy#1837 is invalid on our side, it's piwheels' fault, we cannot do anything about it — they should implement PEP503
bmxp
@bmxp
I have a problem with cherrypy using multiple servers, ip and ports: If several servers are created with cherrypy._cpserver.Server(), then how can I attach an app to a specific server which runs on a specific ip and port?
bmxp
@bmxp
Ok, I found out there is no way to make a link between server and app. The only possibility is to use a hostmap which assigns an app to a combination of ip and port.
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?
bmxp
@bmxp
So what I want is something like: http://127.0.0.1:1234/ and http://127.0.0.1:8080/
bmxp
@bmxp
Yes but it IMHO does not work with two roots. The hostmap in the docs above has /app1 and /app2
Sviatoslav Sydorenko
@webknjaz
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
@MikHulk
Hello Is there any plan to support HTTP/2 in cherrypy ? just curious
Sviatoslav Sydorenko
@webknjaz
It doesn't make sense to have h2 w/o async io
MikHulk
@MikHulk
ah ok. I didn't know that HTTP/2 relies on event driven design. thank you
Sviatoslav Sydorenko
@webknjaz
Technically it doesn't but it is just useless performance-wise.
falconruo
@falconruo
@webknjaz Hey, do we know the memory consumption of the latest cherrypy? I am using cherry 3.8.0 and the peak memory consumption is almost 85MB
MikHulk
@MikHulk
Indeed, the protocols are compatible so there is no need to adopt it in Cherrypy if it does nothing Thx @webknjaz
Sviatoslav Sydorenko
@webknjaz
@falconruo that version is very old
@MikHulk they are not that compatible
MikHulk
@MikHulk
@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.
Sviatoslav Sydorenko
@webknjaz
@MikHulk it's compatible on the high level, but on the low level it's more complex and efficient. For web frameworks, this low level layer matters. By the way, it is recommended that you know how HTTP works if you work with web apps.
MikHulk
@MikHulk
I know HTTP/1.0...
I am learning about upper version
Sviatoslav Sydorenko
@webknjaz
:+1:
Ian Otto
@duper51
@webknjaz Any tips on debugging a read timeout in Cheroot? I'm working through one of the tests and it seems to just fail with a read timeout when data has clearly been sent.
Sviatoslav Sydorenko
@webknjaz
@duper51 I'm not sure, could you plz file an issue or provide more info about this? The only thing I can suggest is to try using low-level tracing but that may prove to be complicated.
Ian Otto
@duper51
Sure thing, idk where to publish the issue. It's regarding the h11 migration. I can push the test that's failing and make a comment with information on reproduction. It's failing on a MakeFile StreamReader with a read timeout. It definitely has been sent this data.
Sviatoslav Sydorenko
@webknjaz
FWIW makefile needs a lot of refactoring
where's the test?
Ian Otto
@duper51
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?
Sviatoslav Sydorenko
@webknjaz
@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 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.