[wp-trac] [WordPress Trac] #17490: cURL fails with timeout when posting to a location that redirects

[WordPress Trac]

#17490: cURL fails with timeout when posting to a location that redirects
--------------------------+-----------------------------
 Reporter:  simsmaster    |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  HTTP          |     Version:  3.2
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+-----------------------------

Comment (by sivel):

 It looks like the issue is the PHP implementation of cURL keeps the same
 Content-Type request header and recalculates the Content-Length for the
 GET.

 Here is a sample of the verbose output from cURL:

 {{{
 * About to connect() to localhost port 80 (#0)
 *   Trying ::1... * connected
 * Connected to localhost (::1) port 80 (#0)
 > POST /post.php HTTP/1.0
 User-Agent: WordPress/3.2-beta2; http://wordpress.trunk
 Host: localhost
 Accept: */*
 Accept-Encoding: deflate;q=1.0, compress;q=0.5
 Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 Content-Length: 7

 < HTTP/1.1 302 Found
 < Date: Fri, 27 May 2011 14:24:14 GMT
 < Server: Apache/2.2.17 (Unix) PHP/5.3.4 mod_ssl/2.2.17 OpenSSL/0.9.8l
 DAV/2 mod_wsgi/3.3 Python/2.7.1
 < X-Powered-By: PHP/5.3.4
 < Location: http://localhost/get.php
 < Content-Length: 43
 < Connection: close
 < Content-Type: text/html
 <
 * Closing connection #0
 * Issue another request to this URL: 'http://localhost/get.php'
 * Violate RFC 2616/10.3.3 and switch from POST to GET
 * About to connect() to localhost port 80 (#0)
 *   Trying ::1... * connected
 * Connected to localhost (::1) port 80 (#0)
 > GET /get.php HTTP/1.0
 User-Agent: WordPress/3.2-beta2; http://wordpress.trunk
 Host: localhost
 Accept: */*
 Accept-Encoding: deflate;q=1.0, compress;q=0.5
 Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 Content-Length: 7

 * Operation timed out after 5000 milliseconds with 0 bytes received
 * Closing connection #0
 }}}

 It looks like there is no way to change this behavior via cURL options.
 So we can check if it is a POST request, if so then don't follow location,
 if a redirect is returned from the POST, call wp_remote_get minus some of
 the bits that would cause it to fail again, and return it's response.

 A proof of concept patch will follow in a few seconds.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17490#comment:11>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software