These are chat archives for cherrypy/cherrypy

10th
Aug 2017
Jason R. Coombs
@jaraco
Aug 10 2017 12:13
Here’s the commit where that test was added - cherrypy/cherrypy@fef7add
@webknjaz I’m starting to agree with your assessment… that the test that’s there is invalid… and CherryPy shouldn’t be testing a CONNECT method unless it’s going to honor the specified protocol for a CONNECT method.
So my inclination would be to drop the test or adapt it to honor the protocol.
Sviatoslav Sydorenko
@webknjaz
Aug 10 2017 12:29
Alright, as a first step I'll change cheroot to return 405 if it's not in proxy mode and will put validation in place and will remove test for CONNECT then.
Jason R. Coombs
@jaraco
Aug 10 2017 12:35
@webknjaz What does this mean for a user who might have written a proxy handler (for a CONNECT method) in CherryPy?
I wonder if a “proxy mode” for cheroot means cheroot is overstepping its scope and it should be the layer above cheroot (CherryPy or alternative) that is responsible for handling that protocol.
I honestly don’t know.
Sviatoslav Sydorenko
@webknjaz
Aug 10 2017 12:48

@jaraco I've added “proxy mode enabled” to CherryPy to maintain compatibility with old mode for now, because it looks like nginx proxy_passes HTTP in a wrong way, but this looks strange to me. According GET http://example.com/page HTTP/1.1 is invalid as well, unless it's a proxy (meaning it should be treated differently as well).

This “proxy mode enabled” would also allow users to proceed with handling CONNECT request (not raising 405), but it will be routed to index handler in CherryPy, so I'd recommend them to use Cheroot directly.

Jason R. Coombs
@jaraco
Aug 10 2017 12:58
The design makes me uneasy, but I unfortunately don’t have time to provide a better suggestion, so I guess we’ll go with it. Thanks for working on this.
Sviatoslav Sydorenko
@webknjaz
Aug 10 2017 14:29
:+1: