[wp-trac] [WordPress Trac] #11428: WP_Http_ExtHTTP response code testing

[WordPress Trac]

#11428: WP_Http_ExtHTTP response code testing
--------------------------+-------------------------------------------------
 Reporter:  arena         |       Owner:  dd32     
     Type:  defect (bug)  |      Status:  new      
 Priority:  high          |   Milestone:  3.0      
Component:  HTTP          |     Version:  2.9      
 Severity:  major         |    Keywords:  has-patch
--------------------------+-------------------------------------------------

Comment(by dd32):

 > Please define "Error condition was hit". I do not see any error /
 exception handling in WP defined/documented so I hardly doubt that with a
 wishy-washy sentence like "Error condition was hit" anything is explained.

 Sure, "A code line which is not supported by the function, And as such,
 will return a WP_Error or false to indicate failure of the function"

 A "Error Condition" is a case where the function can no longer continue,
 In the event that {{{[error] => Operation timed out after 1 seconds
 with 30492 out of 222394 bytes received}}} is recieved, The function
 cannot continue as it has been given incomplete data. It is an Errro
 condition.  Exception handling is a seperate issue and is not suported by
 WordPress.

 > I understood you that you're talking for or against a HTTP-Error
 condition was hit that should be reflected with an WP_Error or not?!?!

 I am seperating the differences between a HTTP level error, and a
 WordPress error.

 A 404 is a HTTP Status code which stands for an error, Nothing more,
 Nothing less.

 That IS the response from the server, Therefor, its not an error where the
 function can no longer continue.  In the event, that the server is
 unreachable, or returns a imcomplete data stream, That is a Error
 condition as there is no data which can be trusted as a response from the
 server.

 From a users perspective, A 404 error in the browser is the UI choice. It
 has been decided that the Users Experience upon hitting a 404 page should
 present a Not found page and appropriate action taken.  The underlying
 HTTP subsystem would've returned that Status from the server.  The Browser
 would also handle the no-connection-present or no-server error
 conditionals (Which in WordPress, would be presented as a WP_Error
 object), Those are Application-level errors, which is distinctivly
 different from a HTTP-level error.


 Looking at the patch, If someone can write a patch which ensures that the
 error condition is only ignored in the event that the data was 100%
 returned and valid, then i'm all for it.

 But as the patch stands, It mearly saying:
  * For any response which is not a 200 and the 'error element' is set, or
 the response was false
   * Then return a WP_Error
  * In the event that the 'error element' is returned, If the headers said
 it was a 200 response, Ignore the error and return the data.
   * In the event that only "HTTP 200 OK\nHeader: Te" was returned, This
 says thats a Valid response. Its not. Thats incomplete data, as the 'error
 element' has said.

 ('error element': The error array key of the returned data)

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