[wp-trac] [WordPress Trac] #17010: Inconsistent handling of HTTP response codes

[WordPress Trac]

#17010: Inconsistent handling of HTTP response codes
--------------------------+------------------------------
 Reporter:  sivel         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  HTTP          |     Version:  3.1
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------------------

Comment (by dd32):

 The specific error code is 52: (from http://curl.haxx.se/libcurl/c
 /libcurl-errors.html)
 {{{
 CURLE_GOT_NOTHING (52)

 Nothing was returned from the server, and under the circumstances, getting
 nothing is considered an error.
 }}}

 If we want to standardise on returning a normal response for 1xx errors, I
 can't find a way to reliable catch it.

 I've tried changing the error check to check for both an empty body, error
 53, and headers are present.. but that resulted in timeouts not being
 caught properly.

 > It looks like cURL only returns a WP_Error if the HTTP code is 100 AND
 the content is blank.
 Scratch that, Its a error condition internally to curl, there's nothing to
 avoid that it seems, cURL will wait for a non-1xx response following a 1xx
 response.. which is pretty much what I expected.

 A 1xx response "requires" a  followup request response, from what I can
 see, it's never mean't to be returned by itself.

 ----

 Lets looks at some rfc's now:
 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
 {{{
 10.1.1 100 Continue

  The client SHOULD continue with its request. This interim response is
 used to inform the client that the initial part of the request has been
 received and has not yet been rejected by the server. The client SHOULD
 continue by sending the remainder of the request or, if the request has
 already been completed, ignore this response. The server MUST send a final
 response after the request has been completed. See section 8.2.3 for
 detailed discussion of the use and handling of this status code.
 }}}

 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
 {{{
 Requirements for HTTP/1.1 clients:
       - If a client will wait for a 100 (Continue) response before
         sending the request body, it MUST send an Expect request-header
         field (section 14.20) with the "100-continue" expectation.
       - A client MUST NOT send an Expect request-header field (section
         14.20) with the "100-continue" expectation if it does not intend
         to send a request body.

 Requirements for HTTP/1.1 origin servers:
 ...<snip>...
       - An origin server that sends a 100 (Continue) response MUST
         ultimately send a final status code, once the request body is
         received and processed, unless it terminates the transport
         connection prematurely.
 }}}

 From that I conclude:
  * cURL is sending an Expect: 100-continue; header, in doing so it's
 allowing servers to respond with 100 messages
  * Servers should NOT just return a 100 code, if it does, and doesnt
 follow up with a valid response (ie. 200) It's breaking the spec and
 client should ignore the request
  * cURL is acting correctly here, Streams and fsockopen() shouldn't be
 accepting the 100 code like they are

  * 101 responses are to tell the client to make the request over a non-
 HTTP supported method, this is effectively a code which can be returned
 (the Upgrade header should be checked) however it's highly unlikely that
 any usage of the WP_HTTP API within WordPress is ever going to come
 accross a real-world usage of such a redirection (Stop using HTTP! Switch
 to FooBar procol version 1337 for continued usage!).

 IMO, lets change streams and fsockopen to bail on 1xx responses.

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