These are chat archives for cherrypy/cherrypy

9th
Aug 2017
Jason R. Coombs
@jaraco
Aug 09 2017 18:01
@webknjaz My first instinct is that CherryPy doesn’t need to support this method natively, but it should not get in the way of an applications implementation of that method… and maybe CherryPy could provide some code examples such as “how to implement CONNECT”. I’m not sure it’s meaningful for a web framework like CherryPy to provide respond to CONNECT by default.
Looking at this test, it doesn’t look like CherryPy is asserting anything other than a request for a CONNECT method returns a ”CONNECT” payload.
I don’t see how that test is invalid. It’s using the CONNECT method, but it’s not attempting to implement RFC7231 as far as I can tell.
How’s it failing?
Sviatoslav Sydorenko
@webknjaz
Aug 09 2017 21:55

@jaraco

  1. In HTTP/1.0 CONNECT is just a reserved method, so there's no explicit rules for processing it, which is probably the reason why routing worked in old implementation and the request reached appropriate handler.
    1.1. Current implementation doesn't populate URI path variable (because it implements modern RFC), which causes CherryPy to fail HTTP handler look-up.
  2. In HTTP/1.1 CONNECT is specified as a method for establishing TCP tunnel through HTTP proxy (specifically for SSL/TLS connections).
    2.1. It is explicitly stated that request-target should be in authority-form
    2.2. CONNECT example.com:3128 HTTP/1.1 is valid (it instructs web proxy to establish connection to host example.com port 3128 and forward there and back all the traffic from the client through existing connection).
    2.3.CONNECT http://example.com:3128 HTTP/1.1, CONNECT /some/path HTTP/1.1, CONNECT example.com HTTP/1.1 are all invalid and should return 400
  3. according to my research it seems that other web-servers tend to return 405 Method Not Allowed unless the appropriate extension/module is enabled
  4. I also think that Cheroot/CherryPy shouldn't try implementing Web Proxy, at least not as its core part.

it’s not attempting to implement RFC7231

Yes, but it's trying to implement RFC7230, section 5.3.3, which restricts request-target to match authority-form, meaning we cannot consume any URI path information from the request, but rather return error if it's there.