[wp-trac] [WordPress Trac] #34053: HTTP API (Curl backend) inappropriately sends Content-Length header on POST requests made through a proxy server CONNECT

[WordPress Trac]

#34053: HTTP API (Curl backend) inappropriately sends Content-Length header on POST
requests made through a proxy server CONNECT
----------------------------+-----------------------------
 Reporter:  petertvs        |      Owner:
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  HTTP API        |    Version:  4.3.1
 Severity:  normal          |   Keywords:
  Focuses:  administration  |
----------------------------+-----------------------------
 When WordPress is configured to communicate with the outside world through
 a HTTP proxy server, using

 {{{
 define('WP_PROXY_HOST', 'some-proxy-server');
 define('WP_PROXY_PORT', '3128');
 }}}

 in '''wp-config.php''', HTTP POST requests that are over HTTPS, and pass
 through the proxy server, get a Content-Length header inserted in the
 CONNECT request, instead of in the headers of the POST request made inside
 the HTTPS tunnel.

 On certain proxy servers configured to parse requests strictly, they will
 reject this outer CONNECT request with a HTTP 400 Bad Request, as the
 Content-Length header should not be there(?)

 Here is an HTTP POST request and response, going via a HTTPS CONNECT
 request (in this case a request for Google's Recaptcha through the Contact
 Form 7 plugin) behind a BlueCoat proxy server configured with tolerant-
 request-parsing off:

 {{{
 CONNECT www.google.com:443 HTTP/1.1
 Host: www.google.com:443
 User-Agent: WordPress/4.3.1; https://staging.testvalley.hants.sch.uk
 Proxy-Connection: Keep-Alive
 Accept-Encoding: deflate;q=1.0, compress;q=0.5, gzip;q=0.5
 Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 Content-Length: 1052

 HTTP/1.1 400 Bad Request
 Cache-Control: no-cache
 Pragma: no-cache
 Content-Type: text/html; charset=utf-8
 Proxy-Connection: close
 Connection: close
 Content-Length: 513

 invalid_request: Your request could not be processed. Request could not be
 handled

 }}}

 To demonstrate this is not a plugin issue, a similar request (a check for
 core updates by clicking 'Check again' on the Updates page in WP-Admin)
 that is also affected:

 {{{
 CONNECT api.wordpress.org:443 HTTP/1.1
 Host: api.wordpress.org:443
 User-Agent: WordPress/4.3.1; https://staging.testvalley.hants.sch.uk
 Proxy-Connection: Keep-Alive
 Accept-Encoding: deflate;q=1.0, compress;q=0.5, gzip;q=0.5
 Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 Content-Length: 193

 HTTP/1.1 400 Bad Request
 Cache-Control: no-cache
 Pragma: no-cache
 Content-Type: text/html; charset=utf-8
 Proxy-Connection: close
 Connection: close
 Content-Length: 513

 invalid_request: Your request could not be processed. Request could not be
 handled

 }}}

 HTTP (not HTTPS) requests, including POST, proceed fine through the proxy.
 HTTPS GET requests also work correctly.

 This seems to be an issue that derives from where '''includes/class-
 http.php''' injects the Content-Length header before dispatching the
 request to the chosen HTTP backend. This header injection does not cause
 issues with a HTTP POST request, but in the case of an HTTPS POST request
 going through the proxy, the Content-Length header ends up in the HTTPS
 CONNECT request to the proxy, rather than the actual request to the server
 that is wrapped inside the established tunnel.


 Commenting out lines 273 and 274 of '''includes/class-http.php''' causes
 the above two requests to succeed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform