[wp-trac] [WordPress Trac] #14786: WP_Http Transport test order refactoring

[WordPress Trac]

#14786: WP_Http Transport test order refactoring
--------------------------+-------------------------------------------------
 Reporter:  hakre         |       Owner:                        
     Type:  defect (bug)  |      Status:  new                   
 Priority:  normal        |   Milestone:  Awaiting Review       
Component:  HTTP          |     Version:  3.0.1                 
 Severity:  normal        |    Keywords:  has-patch dev-feedback
--------------------------+-------------------------------------------------

Comment(by hakre):

 Replying to [comment:20 jacobsantos]:
 > Nothing from what I can read says that it is not allowed ...
 This discussion is out of the scope of this ticket, but the docs clearly
 state that the request-body must be allowed (which implies that  "not
 disallowed" is not enough), otherwise MUST NOT be used in requests. The
 get method specification does not give allowance nor does it provide any
 semantics about the entity-body. Compare to the post method specification
 for example, there you have full semantics.

 But because of your comment I now better understand the issue. If some
 users ask for that bad practice (to say at least, I would say it's
 violating standards and to be considered harmful), then I can understand
 that they might want to be able to send such requests. As this is
 technically not a problem, why to create constraints where it can be kept
 flexible.

 ----

 Replying to [comment:21 jacobsantos]:
 > ...
 Thanks for the summary, i now much better see the whole picture. I suggest
 to commit the first changes here as they don't break anything of the API
 and reduce complexity of the code. And then to continue on the design
 issues. I like the idea that transports can signal availability on an
 installment so that the list of transports can be set up on first use
 (lazy loading). Additionally the transports should provide a method that
 can be used to obtain information about the features that a concrete
 transport supports:

  * SSL
  * Non-Blocking
  * GET with Request-Body
  * Headers
  * Parallel Requests (?)
  * Proxy (?)

 The other ticket(s) already have some useful information, so it could be
 finished there then. One Idea I had is a base transport class that
 provides the needed functionality so that an extending concrete transport
 only need to add some data for this functionality. But that's in the scope
 of #11613 I assume.

 If we can write down a specification of $args values to trigger which
 features, it should be even possible to backwards compatible still provide
 &_get.. / &_post... functions that successfully deliver working transports
 transparently. That would mean, that for most part of the application
 code, no changes would be necessary. We just would replace the current,
 failty caching mechanism with a better strategy based on $args and the
 (then technically correct) list of available transports.

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