Allow hooks for drupal_http_request() request and responses [#786074]

Adding a hook to allow modules to alter HTTP requests and responses would allow modules to do a lot of interesting things:

implement an HTTP cache, so requests can be served without hitting the network.
implement an alternative HTTP client, e.g. based on cURL.
allow or disallow requests to hosts based on whitelists or blacklists.
specify individual timeouts, inject credentials, alter the query string, alter HTTP request headers (e.g. User-Agent).
log network traffic.
modify broken responses, e.g. wrong Content-Type headers or malformed XML.

This patch adds hook_http_request_alter() and hook_http_response(). drupal_http_request() is mostly unchanged except for moving the existing parts around, so the whole request object it built, then possibly altered, and then the network connection is made. If there is interest in this patch, I'll write some tests later.

Comment	File	Size	Author
#18	hook_http_request-786074-16.patch	9.27 KB	c960657
#18
#16	hook_http_request-786074-15.patch	9.32 KB	ramlev
#16
#4	hook_http_request-3.patch	16.49 KB	c960657
#4
#2	hook_http_request-2.patch	16.43 KB	c960657
#2
	hook_http_request-1.patch	10.42 KB	c960657

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

30 April 2010 at 23:00

Status:

Needs review

» Needs work

The last submitted patch, hook_http_request-1.patch, failed testing.

Comment #2

c960657 CreditAttribution: c960657 commented 9 May 2010 at 12:39

Status:

Needs work

» Needs review

File	Size
hook_http_request-2.patch	16.43 KB

Updated and with tests added.

Comment #3

9 May 2010 at 13:30

Status:

Needs review

» Needs work

The last submitted patch, hook_http_request-2.patch, failed testing.

Comment #4

c960657 CreditAttribution: c960657 commented 9 May 2010 at 13:58

Status:

Needs work

» Needs review

File	Size
hook_http_request-3.patch	16.49 KB

Make tests work with unclean URLs.

Comment #5

pwolanin CreditAttribution: pwolanin commented 5 February 2011 at 18:48

Version:

7.x-dev

» 8.x-dev

It would seem like a good place to move toward an OO plugin/strategy pattern in D8

Comment #6

wojtha CreditAttribution: wojtha commented 6 April 2011 at 02:17

Subscribing

Comment #7

RobLoach

he/him

CreditAttribution: RobLoach commented 3 May 2011 at 18:42

I'm liking this.

Comment #8

wojtha CreditAttribution: wojtha commented 3 May 2011 at 19:04

As to the

implement an alternative HTTP client, e.g. based on cURL.

#1081192-14: Verify peer on HTTPS if cURL available (but be careful of built-in cert bundles in the codebase), comment by Dries, April 16, 2011:

Gosh. I'd _really_ love to get rid of drupal_http_request() and rely on something provided by PHP. Should we make CURL a requirement?

Comment #9

pwolanin CreditAttribution: pwolanin commented 3 May 2011 at 22:49

Status:

Needs review

» Postponed

We should wait for a more robust plugin system for core, and then have a pluggable http request system.

I think we should postpone this issue until then.

Comment #10

c960657 CreditAttribution: c960657 commented 9 May 2011 at 19:09

We should wait for a more robust plugin system for core,

Could you elaborate on this? Is there a ticket on file for this?

Comment #11

c960657 CreditAttribution: c960657 commented 18 June 2011 at 12:19

The ticket is #64866: Pluggable architecture for drupal_http_request().

Comment #12

SqyD CreditAttribution: SqyD commented 1 July 2011 at 00:19

subscribing...

Comment #13

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 1 July 2011 at 00:28

Status:

Postponed

» Needs review

I don't see any reason to postpone any issues on the idea that there might one day be a plugin system in core. This being pluggable would just represent another one-off that said plugin system would have to convert.