Problem/Motivation

Some installations require proxy authentication for external communications (as with enterprise scenarios). This leads to failure of RSS feeds, OpenID, Update Status, etc.

Proposed resolution

Implement optional configuration in default.settings.php to define proxy authentication. Configuration settings are used rather than an administration page because proxy authentication is defined only once per system and is often not required.

If enabled, establishes a proxied connection for requests to hosts not explicitly excluded by the configuration (which defaults to 'localhost' and '127.0.0.1'). Only basic authentication is supported.

First rolled (by pwolanin): http://drupal.org/node/7881#comment-3458064
Reviewed (by jpsoto): http://drupal.org/node/7881#comment-3465836
Discussed/reviewed with jhodgdon in IRC: http://drupal.org/node/7881#comment-3785774
Applied to D8, reviewed and passed testing (by pwolanin): http://drupal.org/node/7881#comment-4406026
Tested/verified (by jrbeeman): http://drupal.org/node/7881#comment-4470430

Remaining tasks

Alternative authentications: Suggested hook for drupal_http_request to allow module-based alternative authentications such as Digest/Radius/NTLM/etc.; users requiring these in the meantime might look at NTLMAPS.

HTTPS by proxy: Future implementation may allow this through HTTP 1.1 and cURL.

Persistent connections: Support for configuring pfsockopen instead of fsockopen (as for dedicated servers) is not enabled by the patch.

#1664784: drupal_http_request() has problems, so allow it to be overridden

User interface changes

API changes

Additional (optional) configuration parameters in default.settings.php.

API addition: Adds helper function _drupal_http_use_proxy($host) to determine whether a specified host is in the exclusion list.

Original report by Jhef.Vicedo

I think the RSS feeds don't work if there is proxy server running. The request/connection is somehow being blocked.

The connection should be made first to the proxy and once it is established, then request can made.

I think the core function drupal_http_request() under /includes/common.inc doesn't support this.

One workaround is change the code from:

<?php
switch ($uri['scheme']) {
  case
'http':
    
//$fp = @fsockopen($uri['host'], ($uri['port'] ? $uri['port'] : 80), $errno, $errstr, 15);
?>

into:

<?php
   
//use proxy settings
   
$fp = @fsockopen('proxy2', '8080');
?>

And then create the request by change from:

<?php
$request
= "$method $path HTTP/1.0\r\n";
?>

Into:

<?php
$request
= "$method ".$uri['scheme']."://".$uri['host'].$path." HTTP/1.1\r\n";
?>

And comment out the lines:

<?php
$request
.= implode("\r\n", $defaults);
?>
Files: 
CommentFileSizeAuthor
#429 drupal-7881-429-add-proxy-support-for-http-request.patch5.06 KBDavid_Rothstein
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-7881-429-add-proxy-support-for-http-request.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#422 drupal-7881-422-add-proxy-support-for-http-request.patch5.38 KBeffulgentsia
PASSED: [[SimpleTest]]: [MySQL] 39,355 pass(es).
[ View ]
#409 drupal-7881-409-add-proxy-support-for-http-request.patch6.12 KBmikeytown2
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-7881-409-add-proxy-support-for-http-request.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#406 drupal-7881-406-add-proxy-support-for-http-request.patch5.06 KBmikeytown2
PASSED: [[SimpleTest]]: [MySQL] 39,249 pass(es).
[ View ]
#405 drupal-7881-405-add-proxy-support-for-http-request.patch4.87 KBmikeytown2
PASSED: [[SimpleTest]]: [MySQL] 39,251 pass(es).
[ View ]
#402 7881-402.patch630 bytespwolanin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-402.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#398 drupal-7881-398-add-proxy-support-for-http-request.patch5.09 KBeffulgentsia
PASSED: [[SimpleTest]]: [MySQL] 36,983 pass(es).
[ View ]
#394 drupal-7881-394-1.patch3.89 KBsylus
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-7881-394-1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#394 drupal-7881-394-2.patch996 bytessylus
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-7881-394-2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#388 drupal-7881-388-add-proxy-support-for-http-request.patch4.89 KBmikeytown2
PASSED: [[SimpleTest]]: [MySQL] 36,300 pass(es).
[ View ]
#384 drupal-7881-384-add-proxy-support-for-http-request.patch4.11 KBmikeytown2
PASSED: [[SimpleTest]]: [MySQL] 36,302 pass(es).
[ View ]
#375 diff.patch16.18 KBPatrizio
PASSED: [[SimpleTest]]: [MySQL] 36,261 pass(es).
[ View ]
#370 7881-proxy.patch4.29 KBgwynnebaer
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-proxy_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#341 7881-proxy-please-341.patch4.24 KBpwolanin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-proxy-please-341.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#327 7881-proxy-please-327.patch4.22 KBpwolanin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-proxy-please-327.patch.
[ View ]
#324 proxy_patch-common.inc_.patch2.46 KBRaf
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy_patch-common.inc__0.patch.
[ View ]
#324 proxy_patch-system.admin_.inc_.patch3.21 KBRaf
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy_patch-system.admin_.inc_.patch.
[ View ]
#324 proxy_patch-system.module.patch799 bytesRaf
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy_patch-system.module.patch.
[ View ]
#320 7881-proxy-please-320.patch4.22 KBpwolanin
PASSED: [[SimpleTest]]: [MySQL] 31,553 pass(es).
[ View ]
#297 proxy-with-ssl-support-tentative-001.patch9.04 KBjpsoto
PASSED: [[SimpleTest]]: [MySQL] 24,827 pass(es).
[ View ]
#291 7881-proxy-please-291.patch4.22 KBpwolanin
PASSED: [[SimpleTest]]: [MySQL] 31,490 pass(es).
[ View ]
#289 proxy-with-user-agent-support-001.patch3.59 KBjpsoto
PASSED: [[SimpleTest]]: [MySQL] 24,819 pass(es).
[ View ]
#281 7881-proxy-please-281.patch3 KBpwolanin
PASSED: [[SimpleTest]]: [MySQL] 23,349 pass(es).
[ View ]
#279 7881-proxy-please-279.patch2.42 KBpwolanin
PASSED: [[SimpleTest]]: [MySQL] 23,325 pass(es).
[ View ]
#278 7881-proxy-please-278.patch2.41 KBpwolanin
PASSED: [[SimpleTest]]: [MySQL] 23,320 pass(es).
[ View ]
#277 7881-proxy-please-277.patch2.31 KBpwolanin
PASSED: [[SimpleTest]]: [MySQL] 23,326 pass(es).
[ View ]
#269 7881-d7a4.patch4.42 KBcooperaj
PASSED: [[SimpleTest]]: [MySQL] 22,017 pass(es).
[ View ]
#267 7881-d7a4.patch4.41 KBcooperaj
PASSED: [[SimpleTest]]: [MySQL] 20,429 pass(es).
[ View ]
#257 7881-d7a4.patch4.43 KBcooperaj
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-d7a4.patch.
[ View ]
#247 proxy-patch-6-15.zip77.03 KBstefanhapper
#240 proxy.6.15.patch6.47 KBEmanueleQuinto
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy.6.15.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#235 proxy6.14-D6.dos2unix.patch6.47 KBEmanueleQuinto
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy6.14-D6.dos2unix.patch.
[ View ]
#233 proxy6.14-D6.patch6.66 KBsilid
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy6.14-D6.patch.
[ View ]
#223 proxy-4.patch15.46 KBc960657
Failed: Invalid PHP syntax in modules/simpletest/tests/browser.test.
[ View ]
#220 proxy-3.patch12.4 KBc960657
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy-3.patch.
[ View ]
#218 proxy-2.patch12.43 KBc960657
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy-2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#216 proxy-1.patch12 KBc960657
Failed: Failed to apply patch.
[ View ]
#213 proxy-7881-213.patch7.37 KBbrahms
Failed: Failed to apply patch.
[ View ]
#192 proxy6.13.patch6.76 KBsilid
Failed: Failed to apply patch.
[ View ]
#183 drupal-proxy-6.12.zip75.27 KBrobdinardo
#181 proxy6.12.patch7.22 KBmaykelmoya
Failed: Failed to apply patch.
[ View ]
#176 proxy6.11.patch6.83 KBsilid
Failed: Failed to apply patch.
[ View ]
#166 proxy_7.x-01.patch6.18 KBsilid
Failed: 10503 passes, 32 fails, 0 exceptions
[ View ]
#158 proxy6.10.patch6.83 KBsilid
Failed: Failed to apply patch.
[ View ]
#151 proxy6.9.patch6.83 KBsilid
Failed: Failed to apply patch.
[ View ]
#147 proxy6.8.patch7.78 KBsilid
Failed: Failed to apply patch.
[ View ]
#137 proxy6.6.patch7.84 KBsilid
Failed: Failed to apply patch.
[ View ]
#123 issue-7881-123.patch9.91 KBjcwatson11
Failed: Failed to apply patch.
[ View ]
#118 issue-7881-118.patch11.28 KBlilou
Failed: Failed to apply patch.
[ View ]
#111 7881-drupal-6.4.patch.gz3.17 KBbrahms
#104 7881.patch10.96 KBRobLoach
Failed: Failed to apply patch.
[ View ]
#102 7881-Drupal-6.4.patch10.04 KBarhak
Failed: Failed to apply patch.
[ View ]
#91 7881.patch10.26 KBRobLoach
Failed: Failed to apply patch.
[ View ]
#89 drupal-6.4-proxy-skip_selftest.patch11.25 KBbrahms
Failed: Failed to apply patch.
[ View ]
#85 drupal-6.3-proxy.patch9.96 KBbrahms
Failed: Failed to apply patch.
[ View ]
#85 drupal-6.4-proxy.patch9.96 KBbrahms
Failed: Failed to apply patch.
[ View ]
#83 drupal-7881-83.patch10.29 KBbrahms
Failed: Failed to apply patch.
[ View ]
#81 proxy.patch2.31 KBkaneod
Failed: Failed to apply patch.
[ View ]
Patch.zip73.47 KBLucict
#72 system_proxy-drupal-5.7.tar_.gz2.49 KBwaddles
#57 proxy_11.patch9.23 KBboydjd
Failed: Failed to apply patch.
[ View ]
#51 proxy.patch8.94 KBzxombie
Failed: Failed to apply patch.
[ View ]
#42 proxy.patch4.41 KBzxombie
Failed: Failed to apply patch.
[ View ]
#39 proxy.patch3.79 KBboydjd
Failed: Failed to apply patch.
[ View ]
#34 drupal_intranet_proxy_7.x.diff2.05 KBzxombie
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal_intranet_proxy_7.x.diff.
[ View ]
#25 common-differences.txt1.82 KBdskennedy
#20 add_proxy_settings.patch.txt2.5 KBkillefiz
#14 common.inc_7.patch1.38 KBJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_7.patch.
[ View ]
#13 system.module_4.patch1.01 KBJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in system.module_4.patch.
[ View ]
#8 common.inc_6.patch1.37 KBJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_6.patch.
[ View ]
#6 system.module_3.patch1.03 KBJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in system.module_3.patch.
[ View ]
#5 common.inc_5.patch1.35 KBJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_5.patch.
[ View ]
#4 system.module_2.patch956 bytesJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in system.module_2.patch.
[ View ]
#3 common.inc_4.patch1.37 KBJhef.Vicedo
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_4.patch.
[ View ]
common.inc37.11 KBJhef.Vicedo

Comments

JonBob’s picture

Category:support» bug
Priority:Critical» Normal
Anonymous’s picture

Did this ever get taken care of in 4.5.2. I can't seem to get any feed to work from behind a firewall. Getting error....

Failed to parse RSS feed Microsoft Security Info: 10060 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond..

At home this same feed works fine, so I know it's not the feed.

Thanks,

SlackNet

Jhef.Vicedo’s picture

Category:bug» feature
StatusFileSize
new1.37 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_4.patch.
[ View ]

+1 on having a facility to modify proxy settings...

here's a patch of /includes/common.inc for drupal-4.4.2 version

Jhef.Vicedo’s picture

StatusFileSize
new956 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in system.module_2.patch.
[ View ]

+1 on having a facility to modify proxy settings...

here's a patch of /modules/system.module for drupal-4.4.2 version

Jhef.Vicedo’s picture

StatusFileSize
new1.35 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_5.patch.
[ View ]

patch for /includes/common.inc 4.5.2 version to facilitate rss feeds behind firewall

Jhef.Vicedo’s picture

StatusFileSize
new1.03 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in system.module_3.patch.
[ View ]

patch of /modules/system.module 4.5.2 version to set proxy settings

Bèr Kessels’s picture

hi, tso small issues. one is described at: http://drupal.org/node/9706
The other is that the code is not "drupal compliant". Drupal developrs are (luckily) very picky about spaces, indentation, etc.

Jhef.Vicedo’s picture

StatusFileSize
new1.37 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_6.patch.
[ View ]

i forgot to remove my hardcoded proxy name.. sorry

Ber, which is not drupal compliant?

Steven’s picture

1) New features only get added to CVS/HEAD, not to the 4.5.x branch.

2) 'Blind' variables that cannot be changed through an admin interface are not a good idea.

3) Your proxy codepath ignores the $defaults array completely. At this point in the code, this doesn't just contain default headers but also any extra headers passed to drupal_http_request(). This is not good as they are simply not used anymore.

4) Code style:
//use proxy settings
There should be a space between '//' and text. MInd capitalization and punctuation.

$request = "$method ".$uri['scheme']."://".$uri['host'].$path." HTTP/1.1\r\n";
Rules for string concatenation: never a space between . and a quote, always a space otherwise.

Tab usage: we never use tabs due to editor differences. Your patch contains several.

String quote usage: we prefer single quotes in Drupal to double quotes, except in the case where single quotes would be too hard to read (e.g. backslash escapes should be avoided as well).

Anonymous’s picture

In a very tight setup, users must authenticate to access the proxy, to prevent unauthorised usage, or to track authorised usage.

Can the proxy support also be modified to allow username/password to be supplied to the proxy?

Jhef.Vicedo’s picture

StatusFileSize
new1.01 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in system.module_4.patch.
[ View ]

Thanks Steven.

I hope this patch works and be accepted... This will allow proxy variables to be modified using the admin interface.

Jhef.Vicedo’s picture

StatusFileSize
new1.38 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in common.inc_7.patch.
[ View ]

compliant patch for proxy suport, thanks Steven.

Bèr Kessels’s picture

-1 on this. Please do not introduce more config options. IT makes no sense, since you only set that option once.

Also: you solve a single case of fopen, please look for an overal solution that will solve all drupa fopens, rather than hack into the feed code to fix that specific issue.

* either make the code smarter so it can detect proxy errors (http://drupal.org/node/9706) OR
* add this to conf.php

killes@www.drop.org’s picture

I'd also like to avoid YAS (yet another setting). Can't we include proxies settings.php?

rp0999’s picture

Title:RSS Feeds behind Firewall» Get me past my proxy server
Category:feature» support

I tried to apply the patch and from the fsockopen(): unable to connect to error i get the Warning: Unknown: A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0 error.
I am on the version v4.6.3 on windows with
php
PHP 5.0.5 (cli) (built: Sep 22 2005 10:49:43)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.8, Copyright (c) 2003-2005, by Zend Technol
ogies
with Zend Optimizer v2.5.10, Copyright (c) 1998-2005, by Zend Technologies
apache 2.0.55 for windows and mysql as backend.
Any help or pointers in the right direction much appreciated.
my commons.inc file version is 1.443.3.10
Regards,
Rajesh

karppa’s picture

Category:support» feature

As dlr noted before (http://drupal.org/node/34340), wouldn't it be cleaner to add the proxy support in the core system? Have I missunderstood, but don't I have to patch (http://drupal.org/node/7881) common.inc every time after an update? If it were possible to define the proxy-configuration as an option, it wouldn't be neccesery to do the patch all over again after each update.

I bet there are lots of other corporate users (in addition to dlr and me) behind firewall that aren't able to get aggregated content without proxy support.

killefiz’s picture

Version:» 4.7.2
StatusFileSize
new2.5 KB

I would also love to see the possibility to configure a proxy server as part of the drupal distribution.

Until that happens I have created a patch with the "won't make it into a proper release" hacks from above that applies cleanly to 4.7.2.

magico’s picture

Version:4.7.2» x.y.z
  1. Features only go to HEAD
  2. We must avoid the cluttering of the "admin" settings page for "system" variables like this one, that are defined only once. (Perhaps we should create a special page with all variables in the table, if someone does not like to play with settings.php)
jlwestsr’s picture

Proxy server should be a core based setting. For instance, here at Cingular Wireless all the servers are sitting behind a proxy server as well as the users. So anything that is hosted on this network is forced to access external links through a proxy server.

rediguana’s picture

I need this functionality too. I have just finished dealing with support at my hosting company that have implemented a proxy server for security. This is only going to become a bigger issue as more hosting companies implement similar techniques to increase security of thier servers. Please, can we have a generalised solution - and may it not take 2 years to implement? Unfortunately, I'm not a coder so can't do it myself. I agree that it needs to be generalised not just for RSS feeds, but for any external communication by Drupal.

Elfod’s picture

Version:x.y.z» 5.1

Made the changes described to a fresh install of Drupal 5.1 and it worked like a charm. Thanks ;-)

Would be better if it was just a config settings tho.

dskennedy’s picture

StatusFileSize
new1.82 KB

@#24:

What did you do to get it working with 5.1? I've tried it with my fresh install here and it doesn't work, it fails with the following error:
The feed from BBC News: Education seems to be broken, due to " ".

I've attached the changes I made to my common.inc file.

Mark Matuschka’s picture

To get drupal_http_request() working with a proxy server which requires authentication, you need to add the username and password to the request, like this:

$request = $method . ' ' . $uri['scheme'] . '://' . $uri['host'] . $path . ' ' . "HTTP/1.1\r\n";
$request .= 'Proxy-Authorization: Basic ' . base64_encode("$username:$password") . "\r\n";

where you have set $username and $password appropriately of course.

MWLimburg’s picture

Version:5.1» 6.0

+1 to this feature.

One of the greatest pushes for Drupal that I've seen has been behind proxies, using Drupal as a knowledge base or as an intranet. Some form of proxy awareness would be a godsend. In my instance, I am currently behind a NTLM proxy (which makes life real interesting on Linux) although I've managed to get NTLMaps set up so apt-get (etc, etc) can talk to the outside world. Some method to allow proxy details to be passed to Drupal (whether it's a pointer to the NTLMaps application, or to the main proxy itself) would allow us to restore a serious slab of functionally back to the installation.

I might also point out, that with Drupal6, I now have a permanent alert on my admin page, saying "One or more problems were detected with your Drupal installation. Check the status report for more information." ... why?

"Update notifications are not enabled. It is highly recommended that you enable the update status module from the module administration page in order to stay up-to-date on new releases. For more information please read the Update status handbook page."

So now, it's a security issue.

I feel that this issue is starting to grow in significance.

catch’s picture

Version:6.0» 7.x-dev
Category:feature» bug

All issues are now fixed in 7.x, then backported if applicable.

zxombie’s picture

StatusFileSize
new2.05 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal_intranet_proxy_7.x.diff.
[ View ]

I've attached a patch to common.inc to make drupal_http_request work through a proxy. I've allows the proxy host, port, username and password to be specified.

I don't have a proxy that required authentication so authentication has not been fully tested.

This is against Drupal CVS HEAD.

mooffie’s picture

Perhaps, instead of amending drupal_http_request(), we should make it plugable/replaceable?

We already do that with drupal_mail().

Every once in a while somebody discovers another deficiency in drupal_http_request() and suggests to improve it. I myself had to forgo drupal_http_request in a certain project, in favor of CURL, because I discovered it doesn't behave well in strained environments.

thememex’s picture

Version:7.x-dev» 6.0

+1 on proxy settings.

I'd really like a place to edit in common.inc or through the Drupal interface.

I've been trying to demonstrate Drupal 6.0 inside the corporate network. We have a proxy firewall, so I'm unable to complete the setup with OpenID, Update Status, and RSS. I need to specify (unauthenticated) proxy access to [ip address]:8080.

Check out the post from agentrickard. He provided a link to an fsockopen example

Since the Update Status module is now in the core, and Drupal nags if it isn't on, I do not consider this a feature request. This is a bug. OpenID is now in the core and cannot work for many Intranet sites without an area to specify a proxy. RSS does work under the same environment as well. These individual module developers should not have to create their own proxy module, either.

catch’s picture

Version:6.0» 7.x-dev

All changes get made to 7.x first.

boydjd’s picture

Status:Active» Needs review
StatusFileSize
new3.79 KB
Failed: Failed to apply patch.
[ View ]

Added configuration options to the UI under Site Information. Probably needs to be tweaked some for wording and such.

boydjd’s picture

Title:Get me past my proxy server» Add support for intranet sites behind proxy servers

Probably be changing this tomorrow so that it adds a new link called Proxy Settings rather than throwing under Site Information, but it's a start.

zilla’s picture

okay, i know nada about php, but i found this commentary in a discussion of this specific issue from a web host blocking http requests for security reasons and they offer these ideas:

1) Using the PHP environment variable $_SERVER['DOCUMENT_ROOT'], which returns the absolute path to the web root directory.
2) cURL is another method that could be used.

would option 1 be possible in the current common.inc file as a manual edit? and if so, how?

zxombie’s picture

StatusFileSize
new4.41 KB
Failed: Failed to apply patch.
[ View ]

I've added changed the patch in 39 to include:
* Validation of the proxy port to be a number and in the range of valid tcp ports
* Use a valid port by default in the settings page
* Fix a bug in my original patch with the setting of $auth_string.

boydjd’s picture

@zxombie good catch.

Opinions on creating a new menu item under Site Configuration called "Proxy Settings"? Also, I'm thinking there should be an on/off option.

boydjd’s picture

@zilla the fsockopen method used in this patch is much better than either of those two alternatives.

boydjd’s picture

I'm thinking we should also allow the option of a persistent connection (via a checkbox), and use pfsockopen rather than fsockopen. On a dedicated server, it would make sense to use a persistent connection, which is probably the majority of sites that are stuck inside of an intranet.

zxombie’s picture

StatusFileSize
new8.94 KB
Failed: Failed to apply patch.
[ View ]

@boydjd, I've updated the patch to create a "Proxy Server" page that allows setting the 4 proxy settings. I've added to the description a note that when the proxy host name is empty it will use a direct connection to the internet.

Slim Pickens’s picture

I've applied this patch in a 6.1 test site on my school webserver which is behind a firewall requiring proxy authentication. There were no errors reported.

The Proxy Settings form appears in Administer-->Site Configuration-->Proxy Server and accepts input.

But I'm still getting "HTTP request status Fails" from Status Report and the Aggregator module reports "" The server can't issue HTTP requests".

I appreciate the work that has gone into this, but I am also amazed that this is even still an issue. There must be countless educational/corporate intranet/webservers that must authenticate through an upstream proxy service.

As someone observed, this is not a feature request, it is a design flaw.

I hope this can be resolved sometime soon and built into core. 6.2 perhaps?

Cheers

zxombie’s picture

@Slim Pickens, what method of authentication does the proxy server expect? The patch only implements basic authentication.

MWLimburg’s picture

If you need this environment to support NTLM (which continues to be the bane of many of our existence), you will need to potentially review a solution that uses http://ntlmaps.sourceforge.net/ ... I use this on my Ubuntu machine at work to handle the NTLM Proxy so apt-get (etc) works.

Slim Pickens’s picture

#53 zxombie - the proxy server expects a username and password. I thought the common.inc patch was creating that capability?

Dries’s picture

Status:Needs review» Needs work

Hey guys -- I haven't tested this yet, but it looks reasonable to me. A couple of suggestions:

1. We don't capitalize each word in a sentence or title. Only the first word gets a capital letter. So things like 'Forward Proxy Settings' should become 'Forward proxy settings'.

2. Proxy settings are quite technical. It would be good if there was a little bit of help on the settings page. If my mom reads it, she should probably be able to determine that this is not a page she should make changes to.

3. What is an 'empty Drupal site'?

4. Add an entry to CHANGELOG.txt please.

Given some additional polish, it should be good to go.

boydjd’s picture

StatusFileSize
new9.23 KB
Failed: Failed to apply patch.
[ View ]

I've re-rolled the patch so that it applies cleanly against head. Working on implementing Dries' changes.

Dries’s picture

'Forward Proxy Settings' should be 'Forward proxy settings'.

'the Internet' should be 'the internet'.

'Proxy Server' should be 'Proxy server'.

Etc.

Crell’s picture

Actually "Internet" is a proper noun, and should therefore be capitalized.

waddles’s picture

StatusFileSize
new2.49 KB

I'm attaching a tarball of a module + core patch which enables the use of a http proxy in drupal 5.7. It's based almost entirely on proxy_11.patch at #57 above.

One exception though, TCP port 0 is reserved so I don't allow it.

akolahi’s picture

Thank you for the module/core patch.... does this allow for the option to have only secure https requests to go through a proxy server? That feature would be awesome as it would allow Drupal to run on shared hosting plans (such as GoDaddy). GoDaddy requires https calls to run through s proxy server but not http.

Edit: While my initial post referenced the Drupal 5 patch, I think it would be of great value to separate the http and https calls through proxy options in Drupal 7 for the same reason. Some hosts require only secure https calls to be done through a proxy server.

craigcarboni’s picture

Suggestion for Proxies that require Digest/NTLM authentication.
If the proxy you are authenticating against requires than try NTLMAPS from sourceforge.
NTLMAPS works in Linux as well as Windows or any OS for that matter as it require Python.
I have used it in Ubuntu and Windows XP and it works well.

kaneod’s picture

Version:7.x-dev» 6.2
Status:Needs work» Needs review
StatusFileSize
new2.31 KB
Failed: Failed to apply patch.
[ View ]

Hi all,

I'm new here so sorry if I tread on toes - just wanted to note that the patch in #57 *almost* works behind our basic-authentication proxy at the University of Newcastle for Drupal 6.2. Common.inc is not quite right though and needs to be modified slightly as given in the attached patch. I now have proper update and RSS functionality through the proxy as far as I can tell, though more testing is obviously required.

I also can't confirm that this works for 7.x-dev as I'm not actively involved with HEAD.

RobLoach’s picture

Version:6.2» 7.x-dev

Very cool, I'd love to test it, but I haven't encountered the need of a proxy server. New features have to go into Drupal 7, and then back ported to Drupal 6. It's wonderful to get as many patches and tests out there as possible though, so thanks! If I get the chance, I'll try porting this to HEAD.

brahms’s picture

StatusFileSize
new10.29 KB
Failed: Failed to apply patch.
[ View ]

@boydjd:

I think I found following problem with the patch from your comment#57: your modification of drupal_http_request would by itself work fine in my site (which is behing an ISA proxy with basic authentification) if there wasn't the call for system_check_http_request at the beginning. Here Drupal checks if it is able to load a local page per HTTP request. The relative url for this check is 'admin/reports/request-test' and gets completed to an absolute url (like 'http://www.example.com/admin/reports/request-test' if 'http://www.example.com' is the url of the Drupal Site). This check is now done over the modified drupal_http_request function and it fails in my site because it tries to make the request over the proxy I configured before in the new proxy settings. And because this check fails, drupal_http_request returns with an error and does not try further requests.

So the self_test (system_check_http_request) has to be a direct request on my site and I think on every site behind a proxy to be successful.

To achieve this behaviour I added the parameter No proxy for to the proxy settings. It works like the same parameter in Firefox. If you define something like 'example.com' as "No proxy for", then every request to a site which has the string 'example.com' in it's url is requestet directly, not over the proxy.

With the additions in the patch (against Drupal 7 head) I provide here I could use update status and the feed aggregator behind the proxy.

brahms’s picture

StatusFileSize
new9.96 KB
Failed: Failed to apply patch.
[ View ]
new9.96 KB
Failed: Failed to apply patch.
[ View ]

Hi asilva,

here is the patch from comment#83 above for D6.3 and D6.4. It works for my site behind an ISA proxy server with authentification. On another drupal site I had still troubles with this patch. There I added some code to switch off Drupal's HTTP self test to make the patch work. Tell me if the patch here works for you. If it doesn't I will provide the other patch with the disabled HTTP self test.

To apply the patch for D6.3 please copy the file drupal-6.3-proxy.patch into your Drupal base directory and apply it with the command: patch -p0 < drupal-6.3-proxy.patch.

The 2nd file drupal-6.4-proxy.patch is the same patch as patch file for D6.4

RobLoach’s picture

Status:Needs review» Needs work

Four things in response to the patch at #83:

  1. I'm not quite sure how I feel about a is_in_no_proxy_list() function as it isn't really that descriptive. drupal_in_proxy_list() maybe?
  2. I'm also not sure how I feel about foreaching through the list whenever the drupal_http_request function is called, but can't really think of a cleaner alternative.
  3. $output .= '<li>'. t('basic configuration options for .... The space before and after the period is part of Drupal 7 coding standards ;-) .
  4. Is there anywhere else that the proxy settings could live? They seem pretty small for just one page.
brahms’s picture

Hi Rob and thanks for your response.

I'm not quite sure how I feel about a is_in_no_proxy_list() function as it isn't really that descriptive. drupal_in_proxy_list() maybe?

I suggest to rename the function is_in_no_proxy_list() to drupal_is_proxy_exception(). But I'm not sure if it's good to use the suffix drupal_ for this internal helper function. Wouldn't it be better to name it _is_proxy_exception() instead?

2. I'm also not sure how I feel about foreaching through the list whenever the drupal_http_request function is called, but can't really think of a cleaner alternative.

I agree with your concern. Maybe it would be a better alternative to use an additional variable proxy_enabled which would be represented by a new checkbox labeled "Use proxy server" in the proxy settings page? Then the foreaching through the list would only be necessary when "Use proxy server" is checked.

3. $output .= '<li>'. t('basic configuration options for .... The space before and after the period is part of Drupal 7 coding standards ;-) .

Shame on me, I used ancient coding convention for string concatenations (Drupal 4 I think...). I'll adjust the syntax in my next patch file.

4. Is there anywhere else that the proxy settings could live? They seem pretty small for just one page.

You are right, but looking at D7's site configuration menu I find some other small settings pages like "Clean URLs", "File system", "Image toolkit" or "Error reporting". On the other hand I don't feel that the proxy settings would match with any of them from a topical point of view. So I suggest to keep the proxy settings on their own page for now. Maybe in the future someone will collect all those small pages into one or more bigger pages?

Please tell me what you think of my suggestions, so I will be able to modify my patch.

brahms’s picture

StatusFileSize
new11.25 KB
Failed: Failed to apply patch.
[ View ]

Hi rizamp,

here is a patch for D6.4 with the disabled self test. But in the meantime I found a better replacement for the problem I had on one of my sites behind a proxy server. I had to enable the reverse_proxy setting in settings.php:

$conf = array(
   'reverse_proxy' => TRUE,
);

With this setting the http self test workes fine for me. please try to enable the reverse_proxy setting, before you apply the new patch and disable the http self test (by checking the checkbox "Skip HTTP self test" at the end of the proxy settings page).

If the proxy patch still does not work on your site and your proxy server regards authentification: be sure that your proxy server accepts "basic authentification method". If he does not allow basic authentification but only allows other methods like Digest, Radius or NTLM the proxy patch won't work. It works only for basic authentification (or if no proxy authentification is required at all).

RobLoach’s picture

Another thing we have to think about is testing. Is there anyway to create an effective SimpleTest for this for self-testing?

RobLoach’s picture

Title:Add support for intranet sites behind proxy servers» Add support for proxy servers
Status:Needs work» Needs review
StatusFileSize
new10.26 KB
Failed: Failed to apply patch.
[ View ]
  • Removed the is_in_no_proxy_list entirely for a stripos call
  • Fixed some strings that didn't seem that helpful
  • Added hook_help text
  • Fixed some of the minor logic which looked kind of weird (variable scope issues)
  • Replaced != '' with calls to empty()
  • Removed the fieldset in the settings, following what they have for Clean URLs, and other settings with just straight textfields
  • Logic in the validation wasn't optimal

To test:

  1. Apply patch, clear cache
  2. Visit admin/settings/proxy and enter your proxy settings
  3. Make a PHP call using drupal_http_request
RobLoach’s picture

Category:bug» feature

... And I'd consider this a feature.

markus_petrux’s picture

Hi,

This is interesting feature, however I believe the word "proxy" used here might be confusing with different kinds of proxies. For instance, default/settings.php use "reverse_proxy" variables for something different.

I would suggest to be a bit more explicit and use "forward_proxy" or something similar as prefix for variables, etc.

brahms’s picture

Hi Rob,

your fixes look good and make the code cleaner. But after applying your patch from comment#91 I get following error when I access my site:

Fatal error: Can't use function return value in write context in /var/www/dev/d7head/includes/common.inc on line 445

The reason for this is that empty() only checks variables as anything else will result in a parse error. In other words, the following will not work: empty(trim($name)) or - like it is done in common.inc - !empty(variable_get('proxy_server', '')) and !empty(variable_get('proxy_username', '')).

RobLoach’s picture

Status:Needs review» Needs work

Hi subru77, unfortunately this can't be implemented through a module because it requires modifying the drupal_http_request function. We could implement a hook in drupal_http_request to expose how HTTP requests are made. Then we could create add on module that could make different kinds of requests, like HTTP requests, HTTPS requestions, FTP requests, etc. But that would have to be thought about, and still wouldn't work if we required a proxy in from of the request..... Thoughts?

Thanks for taking a look at it, brahms. Is that the only issue you saw with it?

brahms’s picture

Hi Rob,

I'm not shure if the two places in code with empty(variable_get()) are the only issues. I just tested the code (with fixes for the empty issue) on my site behind an ISA proxy. First it didn't work because the variable drupal_http_request_fails had been set to 1 before. This caused a call to the self test (function system_check_http_request) and the self test always seems to fail on my site. The reason for this may be the special network configuration I have to use to reach my customer's site. I am connecting to the web server over an SSH tunnel and there is a network address translation configured between the client I use and the web server.

If I set the variable system_check_http_request) to 0 or delete the variable everything works fine. Starting the update status check I am able to connect from my site to the drupal.org update server.

So I think the patch itself works fine. But I am not sure if Drupal's http self test is working from behind a proxy server. (This is why I tried a piece of code which turns of the self test as I provided in my comment#89) In the next days I will visit my customer with the affected Drupal site. There I'll try to check the self test in a network environment without the SSH tunnel and without the NAT.

EDIT:
I just returned from a visit at my customer. I had enough time there to test the code and everything worked fine including the http self test. For me - and much more: for Drupal - it would make sense if your code from comment#91 will make it's way into core after the empty issue has been fixed.

Dries’s picture

Yep, the !empty() is broken. This patch looks close though. :)

yellek’s picture

A workaround for those not comfortable patching Drupal is to use cntlm (http://cntlm.sourceforge.net/) and then using apache to rewrite the URL to point to the cntlm proxy. You then need to alter the URL of what you are looking for to point to your local box. I have posted an example of configuring update module to authenticate with an IIS proxy at http://drupal.org/node/172708#comment-1003511.

arhak’s picture

StatusFileSize
new10.04 KB
Failed: Failed to apply patch.
[ View ]

same as #91 backported to Drupal 6.4

  • corrects the diff context respect Drupal 6.4
  • corrects the empty calls to variables
  • adds one line to make a callback be valid
dankinon’s picture

I applied the patch provided in post #102 to a fresh drupal-6.4 installation without issue (thank you for that). After configuring my proxy server I still can't check for updates. I am now getting the HTTP Request Self-Test error. I followed the instructions in post #89 to enable reverse_proxy, that didn't work for me either. I'm going to attempted to patch drupal with the patch from post #89 (drupal-6.4-proxy-skip_selftest.patch) but I have to mess with it first. In the mean time can someone answer these questions:

- Since I'm getting the Self-Test error should my update checks still be failing?

- Does someone have another solution to the Self-Test problem.

- It seems like most people applied the patch (#91 or #102) like I did and were able to get updates. Is this true or did the rest of you have to do something more to get it to work? The reason I ask is I have been hitting my head on this for 2 weeks and can't get it to work.

Thanks

RobLoach’s picture

Status:Needs work» Needs review
StatusFileSize
new10.96 KB
Failed: Failed to apply patch.
[ View ]

I'm having second thoughts on this. Instead of adding this straight into core, would we be able to create some kind of hook that would manage altering the request so that if we wanted a proxy contrib module to handle this, it could?

Anyway, here's a patch with the !empty() fix along with an added user permission (administer proxy configuration) because you don't want to give your administrator user team permission to see your proxy server password......

arhak’s picture

is this for D5/6/7?

I'm having second thoughts on this. Instead of adding this straight into core, would we be able to create some kind of hook that would manage altering the request so that if we wanted a proxy contrib module to handle this, it could?

+1 of course!!!

mooffie’s picture

I'm having second thoughts on this. Instead of adding this straight into core, would we be able to create some kind of hook that would manage altering the request so that if we wanted a proxy contrib module to handle this, it could?

+1

I suggested this in comment #35. On the other hand, I see people are feeling very strongly that this proxy thing should be in core.

====

It will be interesting to see how this plug/hook mechanism will be implemented. It will require only few lines of code, but nevertheless we should "standardize" the way we "plug" custom code into Drupal. I'll have to do the same for format_date() (to enhance i18n support). drupal_mail() too has a "plug" mechanism and it could be replaced with the one we finally settle on.

arhak’s picture

about the mail there is some work already done http://drupal.org/project/smtp, but it doesn't seems to be proxy aware

Dries’s picture

I'd prefer to have this in core, but I can be convinced (as always).

If someone can confirm that this solution works, I'm ready to commit it to core.

We should probably add a CHANGELOG.txt entry though.

brahms’s picture

StatusFileSize
new3.17 KB

I can confirm that the most recent patch from Rob in comment#104 works in following environments:

  • Drupal 6.4 Site behind a proxy server without authentification
  • Drupal 6.4 Site behind a proxy server which allows basic authentification

(I tested those Drupal 6.4 Sites with a back port of the patch, because I didn't have the chance to install Drupal 7 in those environments. I include this backported patch here as g-zipped file for Drupal 6.4).

Though there are proxy configurations where the solution will not work (if there is another authentification method than basic authentification required) I think having the given solution here in core is an important step for bringing Drupal to enterprise environments. Nevertheless we should continue to work on solutions for the other authentification methods, but this should go into a new issue.

arhak’s picture

I tested #91 backported to D6 in #102 on Drupal 6.4 behind a proxy server without authentification

Slim Pickens’s picture

I vote for inclusion in core. I work in public education. Our State department has more than 1600 schools - all of them are obliged to use a proxy server for internet access. The other 5 Australian States education departments would operate similarly.

Surely a proxy server is the norm for corporate environments? Proxy setup should be a part of the site configuration through core. If you don't need it, don't configure it. We're talking a few lines of code here. No biggie.

Cheers

RobLoach’s picture

The patch at #104 still applies.

Dries’s picture

Did someone test #104?

keith.smith’s picture

Status:Needs review» Needs work

On a quick code style and string review, there are several concatenation operators that aren't set off with spaces, plus several code comments not ending in a period. Also, one of the things we need to clean up (in another patch) is the variety of ways we show examples. This patch uses "eg.". Elsewhere in code we have "e.g.," and "Example: xxxx" and "Example: xxx". As long as this patch is internally consistent and hits one of the existing styles it should be fine, especially since there are other issues in the queue to conform all these to a single standard.

What about:

+    '#description' => t('The host name of the proxy server, eg. localhost. If this is empty, it will be assumed that there is already an existing connection to the Internet.')

The host name of the proxy server. Leave empty if your site has an existing connection to the Internet or does not use a proxy server. Example: localhost.

+    '#description' => t('The password used to connect to the proxy server. This is kept as plain text.', '')

The password used to connect to the proxy server, if necessary. Warning: This password is stored as plain text.

+    '#description' => t("A comma seperated list of sites that don't require use of the proxy server.")

"comma seperated" should be "comma-separated".

+    'administer proxy configuration' => t('Configure if connecting to the Internet requires a proxy connection.'),
+    'description' => 'Configure settings when the site is behind a proxy server.',

These could just be "Configure proxy server settings."

I can roll some of these changes into a new patch tomorrow if nobody beats me to it.

lilou’s picture

Status:Needs work» Needs review
StatusFileSize
new11.28 KB
Failed: Failed to apply patch.
[ View ]

Patch #104 modified according comment #117.

Dries’s picture

Status:Needs review» Needs work

Doesn't seem to apply anymore for me ...

jcwatson11’s picture

Version:7.x-dev» 6.5
Status:Needs work» Needs review
StatusFileSize
new9.91 KB
Failed: Failed to apply patch.
[ View ]

The attached patch works on my installation of Drupal 6.5. Please review. Looks like 2 hrs, 33 minutes. A new record! Hurraaahhh!

IT-Cru’s picture

patch #123 patch without errors for my 6.5, but in status report HTTP request status fails and check manually Drupal core update status also fails. Proxy settings are correct without auth.

patch #123 removes slowing down from update-status module behind a proxy.

Has someone other infos?

brahms’s picture

@Gos77:

Just some things you can try to make the proxy settings work on your site:

reverse proxy settings
I had to enable the reverse_proxy setting in settings.php to make HTTP connections work on my site.
Drupals HTTP Self Test and the variable drupal_http_request_fails
When the HTTP self test in Drupal fails, Drupal sets the variable drupal_http_request_fails to 1. This is the intended Drupal behaviour and it was the case on my site before I applied the proxy patch. Then I applied the patch but though the proxy patch itself would work, update status still failed because the self test did not reset the variable to 0. I had to reset the variable by SQL (setting the column value to b:0; in the variable table) to make the proxy connection work. An alternative way is to delete the variable drupal_http_request_fails from the table. (This is no bad hack because Drupal itself writes this variable into the table once the self test fails. If Drupal's self test on your site never had a problem, there is also no row for the variable drupal_http_request_fails in the table.)
mot’s picture

As in #125 me tends to add the remark to think about stuff like this: if the self-test request fails, drupals internal logic will ZAP any further http request. Adding a proxy in this whole drupal-http logic is not only imlementing it the technical way. The whole dataflow needs to be thought of. I would love to see proxies out of drupal therefore, it makes configuration too complex. A reverse proxy transparently configured somewhere else can do the job as well.

Instead of this, an own connection and transport class for php5 based druapl version(s) might lead to a more and propper way to solve such things. in this case, you could switch to a simple http proxy transport class instead of the default http one.

IT-Cru’s picture

works for my blank 6.5 with patch from #123 and hint #125 .. thx

mot’s picture

Just reviewd the patch. Looks OK for me so far (6.5 patch). Right now I still have no Idea to solve the problem with a sleaner integration if the http self test fails. I had self test fails with DNS problems but they recovered automatically. Why doesn't this happen here. Any Idea brahms, Gos77?

boydjd’s picture

Version:6.5» 7.x-dev

This is a feature request, and as such, goes to HEAD, not 6.x.

Looks like the patch doesn't apply to HEAD cleanly anymore, I'll re-roll when I find a spare moment. :)

boydjd’s picture

Status:Needs review» Needs work

Changing to CNW, since it doesn't apply anymore.

Crell’s picture

No, new features go only against the dev version, regardless of how long they've been requested. Sometimes people maintain backport patches of them, but they do not go into core. Of course, this has to get committed to Drupal 7 first.

mooffie’s picture

Why not use cURL instead of implementing it ourselves? As a bonus, we'll get its 'timeout' feature (it's good for Aggregator).

For Drupal 7, we could define a Drupal::HTTP interface. The default implementation will be the current one. A 'cURL' module, when enabled, will plug in its own implementation.

silid’s picture

StatusFileSize
new7.84 KB
Failed: Failed to apply patch.
[ View ]

without getting into the politics of whether or not to backport here is my patch for 6.6 - it works for me, others may find it useful as i found there patches extremely helpful.

silid’s picture

StatusFileSize
new7.78 KB
Failed: Failed to apply patch.
[ View ]

Now I am back at work I have attached a patch file for Drupal 6.8 - I hope this helps anyone who needs it.

Nitin - have you tried anything else that requires proxy such as checking for module updates - does that work?

silid’s picture

StatusFileSize
new6.83 KB
Failed: Failed to apply patch.
[ View ]

There have been some changes in 6.9 that affect the patch. Try this version, it works for me.

roball’s picture

I can confirm the 6.9 proxy patch to work fine with D6.9. Thank you silid!

RobLoach’s picture

If we got this into Drupal 7, a patch for Drupal 6 would be very easy. As a side note, #64866: Pluggable architecture for drupal_http_request() would be helpful to stick proxy support in contrib.

borzoj’s picture

Hi everyone!

The patch outlined in the original post didn't work on our proxy. We needed to leave this bit that the author advised to comment out:
$request .= implode("\r\n", $defaults);
With this line commente dproxy complained about missing content-length header. With the line in it works.
Cheers,
Michal

silid’s picture

StatusFileSize
new6.83 KB
Failed: Failed to apply patch.
[ View ]

Here is a patch for 6.10

I haven't tested this so I don't know that it works. Please give feedback

IT-Cru’s picture

patch from #158 working fine for me for D6.10

only getting (Stripping trailing CRs from patch.) for all three patched files while patching.

Crell’s picture

Priority:Normal» Critical

Feature additions do not get committed to stable branches, unless it is necessary to close a security hole. Getting this into Drupal 7, however, is something that really does need to happen. Can we focus on that? (Even if it were to go into D6, it won't until it's landed in D7. Focus your efforts there.)

roball’s picture

Crell, I know that this is the rule - but there is no rule without exceptions. For example, see http://drupal.org/node/243524 and http://drupal.org/node/276174 that now went into 6.10 without being a security fix.

This issue is in fact a security fix because the lack of proxy support breaks the Update status module on servers behind a proxy, with the consequence that it no longer warns you about essential security updates. It's not an option that some may want to enable because it's a fancy feature - it's essential to work behind a proxy. Without proxy support, all those servers are locked away from using Drupal 6 at all. So I don't see this patch as a new feature, but rather as a critical bug fix for the Update status, Aggregator and other modules to work.

The D6 patch is working excellent - what's so hard in porting it to D7?

silid’s picture

Status:Needs work» Needs review
StatusFileSize
new6.18 KB
Failed: 10503 passes, 32 fails, 0 exceptions
[ View ]

This patch has been made

Status:Needs review» Needs work

The last submitted patch failed testing.

RobLoach’s picture

Missing the is_in_no_proxy_list() function?

mabland’s picture

Patch for 6.10 works great for me for http requests. But it appears that https requests are not proxified so any module that uses https, such as OpenID, does not work - request times out.

silid’s picture

Hmm. That appears to be true. I must say that I have never needed to access https by proxy and so didn't realise, but looking at the patch it doesn't do anything to https requests at all.

So in other words, it isn't broken it just hasn't ever done it. I will have a look at the patch when I get time but feel free to submit your suggestion.

Si

silid’s picture

StatusFileSize
new6.83 KB
Failed: Failed to apply patch.
[ View ]
chinko’s picture

I applied the 6.11 patch in #176 and I have the 'available updates" report working for the very first time on a PC and Drupal servers in our company. Thanks for all the great work.

However our team is debating whether we should start the precedence of patching the core. If we do, when we upgrade to future 6.x releases, we will have to keep patching (either relying on someone releasing a patch or we create the patch ourselves).

Proxy support is essential in a corporate environment. D7 supports proxy but it is still a long way away.

Not being able to check "available updates" is a security risk. Including this patch into the next 6.12 release as a security fix will make the life of many corporate Drupal users easier and is another step towards getting Drupal wider acceptance as an enterprise CMS.

Thanks.

maykelmoya’s picture

StatusFileSize
new7.22 KB
Failed: Failed to apply patch.
[ View ]

This is 6.11 patch updated for 6.12.

robdinardo’s picture

StatusFileSize
new75.27 KB

Attached file contains the three files to add proxy support to D 6.12

chx’s picture

Priority:Critical» Normal

I am closing this issue and deleting every "I tried to patch" comment from it and then reopen.

chx’s picture

Please focus on getting a working patch for HEAD (http://drupal.org/node/320). Also, please refrain from posting questions regarding 'how to apply patches' and 'why this is not in Drupal N". Those who do will be rewarded with a two week ban.

Damien Tournoud’s picture

I've done my best to ignore the horrible // PROXY-HACK comments, so here is a review of the patch in #181.

<?php
+      $proxy_not_required = is_in_no_proxy_list($uri['host']);
+      if ((
variable_get('proxy_server', '') != '') && (FALSE == $proxy_not_required)) {
+       
$proxy_server = variable_get('proxy_server', '');
+       
$proxy_port = variable_get('proxy_port', 8080);
+       
$fp = @fsockopen($proxy_server, $proxy_port, $errno, $errstr, 15);
+      }
+      else {
      
$fp = @fsockopen($uri['host'], $port, $errno, $errstr, 15);
+      }
?>

Drupal doesn't use value-as-first-component comparisons. You can simply rewrite that as $proxy_not_required && ($proxy_server = variable_get('proxy_server', ''))

<?php
      
break;
     case
'https':
      
// Note: Only works for PHP 4.3 compiled with OpenSSL.
?>

No support for HTTPS (via the CONNECT proxy command)? It seems like this could be useful in several use cases I can think about.

<?php
+  if ((variable_get('proxy_server', '') != '') && (FALSE == $proxy_not_required)) {
+   
$path = $url;
+  }
+  else {
  
$path = isset($uri['path']) ? $uri['path'] : '/';
   if (isset(
$uri['query'])) {
    
$path .= '?'. $uri['query'];
   }
+  }
?>

This indentation is wrong, and same remark as above for the condition.

<?php
+  if ((variable_get('proxy_username', '') != '') && (FALSE == $proxy_not_required)) {
+   
$username = variable_get('proxy_username', '');
+   
$password = variable_get('proxy_password', '');
+   
$auth_string = base64_encode($username . ($password != '' ? ':'. $password : ''));
+   
$defaults['Proxy-Authorization'] = 'Proxy-Authorization: Basic '. $auth_string ."\r\n";
+  }
?>

Same remark.

<?php
+function is_in_no_proxy_list($host) {
$rv = FALSE;

$proxy_exceptions = variable_get('proxy_exceptions', '');
+  if (
FALSE == empty($proxy_exceptions)) {
+   
$patterns = explode(",",$proxy_exceptions);
+    foreach (
$patterns as $pattern) {
+     
$pattern = trim($pattern, " ");
+      if (
strstr($host,$pattern)) {
+       
$rv = TRUE;
+        break;
+      }
+    }
+  }
+  return
$rv;
+}
?>

The function is poorly named and it is not documented.

The condition (that uses type-agnostic comparison on the result of strstr()) is severely broken: it would allow only partial matches that do not start at the first characters (ocalhost will match localhost, but localhost will not match localhost).

We probably want this match to be either on the hostname or on the IP address. This is not possible right now.

<?php
+/**
+ * Form builder; Configure the site proxy settings.
+ *
+ * @ingroup forms
+ * @see system_settings_form()
+ */
+function system_proxy_settings() {
+
$form['forward_proxy'] = array(
+   
'#type' => 'fieldset',
+   
'#title' => t('Forward Proxy Settings'),
+   
'#description' => t('The proxy server used when Drupal needs to connect to other sites on the Internet.'),
+  );
$form['forward_proxy']['proxy_server'] = array(
+   
'#type' => 'textfield',
+   
'#title' => t('Proxy host name'),
+   
'#default_value' => variable_get('proxy_server', ''),
+   
'#description' => t('The host name of the proxy server, eg. localhost. If this is empty Drupal will connect directly to the internet.')
+  );
$form['forward_proxy']['proxy_port'] = array(
+   
'#type' => 'textfield',
+   
'#title' => t('Proxy port number'),
+   
'#default_value' => variable_get('proxy_port', 8080),
+   
'#description' => t('The port number of the proxy server, eg. 8080'),
+  );
$form['forward_proxy']['proxy_username'] = array(
+   
'#type' => 'textfield',
+   
'#title' => t('Proxy username'),
+   
'#default_value' => variable_get('proxy_username', ''),
+   
'#description' => t('The username used to authenticate with the proxy server.'),
+  );
$form['forward_proxy']['proxy_password'] = array(
+   
'#type' => 'textfield',
+   
'#title' => t('Proxy password'),
+   
'#default_value' => variable_get('proxy_password', ''),
+   
'#description' => t('The password used to connect to the proxy server. This is kept as plain text.', '')
+  );
$form['forward_proxy']['proxy_exceptions'] = array(
+   
'#type' => 'textfield',
+   
'#title' => t('No proxy for'),
+   
'#default_value' => variable_get('proxy_exceptions', 'localhost'),
+   
'#description' => t('Example: .example.com,localhost,192.168.1.2', '')
+  );
$form['forward_proxy']['proxy_skip_selftest'] = array(
+   
'#type' => 'checkbox',
+   
'#title' => t('Skip HTTP self test'),
+   
'#description' => t('Skip HTTP request self test.'),
+   
'#default_value' => variable_get('proxy_skip_selftest', '0'),
+  );
$form['#validate'][] = 'system_proxy_settings_validate';
+
+  return
system_settings_form($form);
+}
?>

This form should use the new autodefault feature of system_settings_form() in D7.

<?php
+/**
+ * Validate the submitted proxy form.
+ */
+function system_proxy_settings_validate($form, &$form_state) {
// Validate the proxy settings
$form_state['values']['proxy_server'] = trim($form_state['values']['proxy_server']);
+  if (
$form_state['values']['proxy_server'] != '') {
+   
// TCP allows the port to be between 0 and 65536 inclusive
+    if (!is_numeric($form_state['values']['proxy_port'])) {
+     
form_set_error('proxy_port', t('The proxy port is invalid. It must be a number between 0 and 65535.'));
+    }
+    elseif (
$form_state['values']['proxy_port'] < 0 || $form_state['values']['proxy_port'] >= 65536) {
+     
form_set_error('proxy_port', t('The proxy port is invalid. It must be between 0 and 65535.'));
+    }
+  }
+}
?>

$form_state['values']['proxy_server'] != '' should be strlen($form_state['values']['proxy_server']) > 0, or "0" will not match. The two error messages should be collapsed in one.

FrankT’s picture

Could anyone give me a hint where I have to enter the settings of the proxy server (IP, Port, maybe authentication) with proxy6.12.patch? I searched the issue with no idea on that...

roball’s picture

Administer -> Site configuration -> Proxy Server (admin/settings/proxy)

IT-Cru’s picture

Hi roball .. patch from #181 works fine for my 6.13 installation.

silid’s picture

StatusFileSize
new6.76 KB
Failed: Failed to apply patch.
[ View ]

As requested here is a patch for 6.13 - I haven't reviewed the suggestions or made any amendments to the 6.11 patch I last uploaded except to apply it to 6.13.

As mentioned previously I haven't written the code included here but have produced the patch from other code submitted in the thread to help other users.

The 'horrible // PROXY-HACK comments' are to make it easier for me to roll the patch from one version to the next.
It doesn't use any D7 feature because it is a patch for D6.

I haven't yet upgraded my site to 6.13 so this is untested but I see no reason why it shouldn't work. When I get some time I may try to take all feedback into consideration but that won't be soon.

roball’s picture

Thanks a lot silid, your patch works fine with 6.13 :-)

Damien Tournoud’s picture

Status:Needs work» Closed (won't fix)

As far as I understand, nobody wants this feature to go into D7. Marking as won't fix accordingly.

If you do want this to go into Drupal 7, please reroll a patch taking into account my comments in #187 and previous remarks by others.

silid’s picture

Status:Closed (won't fix)» Needs work

It will get the work when there is time. This thread is full of people that want this feature.

Damien Tournoud’s picture

Status:Needs work» Closed (won't fix)

Until we have a proper patch for this, please let the status at "won't fix".

roball’s picture

Status:Closed (won't fix)» Needs work
Damien Tournoud’s picture

Status:Needs work» Closed (won't fix)

Still waiting for a proper patch.

silid’s picture

Status:Closed (won't fix)» Needs work

The handbook says that 'needs work' is defined as:

The patch needs additional work before it should be reviewed. The author of the patch may indicate that it is incomplete, or the patch has gone through the reviewing process and has received feedback about areas where it needs improvement.

where as 'won't fix' is defined as:

It has been decided that this issue will not be fixed. This includes feature requests that are deemed to be outside the scope of the project, and bug reports that cannot be reproduced or are unsupported.

By your own comments you have described it as a 'needs work', but for some reason you don't want it to say 'needs work' until the work is done. See http://drupal.org/node/156119 for details.

Crell’s picture

I believe the point is that since no one is trying to make a Drupal 7 version of this patch, that must mean that "it has been decided that this issue will not be fixed". If it was going to be fixed, someone would have taken then 20 min to make a Drupal 7 version of it rather than rerolling a Drupal 6 version forever, which is a dead end.

Take-away: Work on getting better proxy support into Drupal 7 and stop wasting time on anything else. This thread is too long already. Those who keep rolling Drupal 6 versions in this issue, I'm looking at you...

David Strauss’s picture

Title:Add support for proxy servers» Add support to drupal_http_request() for proxy servers

Who actually needs this feature?

Also, re-titling to reflect that this is for upstream proxies, not downstream (like Varnish in front of Drupal).

roball’s picture

Are you kidding?

Thousands of people who want to/must run Drupal on a server behind a proxy *needs* it.

glowrocks’s picture

I'm confused. I run drupal behind a firewall and need to use a proxy. Is this hard to understand?

Many many thanks to those who provide this very essential patch.

I *hate* patching my site; it's a maintenance nightmare and my management isn't happy.

And no relief planned for Drupal 7?

What's wrong with this picture?

Anyway, thanks again to those who provide this critical patch!

glowrocks’s picture

Another note: it's in no way a waste of time to make my site work as required by my management. Have we been taken over by "kids" w/no real responsibilities and no real life experience?

What's a waste of time is me and many others having to find and apply this patch every time drupal is updated; the right thing to do is *fix the damn problem*, not hide behind "policies."

Damien Tournoud’s picture

Status:Needs work» Active

The right thing to do is for *someone* to roll a patch for *Drupal 7*, so that it can be committed there. Apparently nobody is willing here to do that simple thing... how can I not conclude that nobody wants this feature?

Come on, people.

glowrocks’s picture

Status:Active» Needs work

I'm probably not the right person to roll that patch, but will give it some consideration.

glowrocks’s picture

Seriously, the problem may be that the folks who need the proxy capability may be like myself and not really in a position to contribute code. Hence, we're reduced to writing grumpy posts :-)

Crell’s picture

glowrocks: If your management hates how much time you spend repatching Drupal, tell them that you can instead spend a couple of hours getting it patched in Drupal 7 so that after you upgrade to D7 you'll never have to run a forked version of Drupal again (at least not for this reason). That's how open source works. :-) What's wrong with this picture is that no one who needs this feature is willing to take any time at all to carry it home so that it can be solved. Help yourself by helping Drupal. It won't happen unless someone steps up to work on it.

roball’s picture

"Apparently nobody is willing here to do that simple thing". Not true - see #166 - silid has already posted a patch for D7, but the validation failed for some reason. If you say that is so simple, or other "Drupal core people" mention it only takes 20 minutes, so why do you waste your time in making this thread more end more endless instead of helping out with that "easy 20 minutes work"? Not everybody here has these skills, but a lot simply need this patch for D6 now!

glowrocks’s picture

Thanks Crell. I probably read this thread too quickly; I came away with the impression that patches were being rejected as no one saw this as a problem.

I wanted to make the case that this is a problem.

If the meta problem is that no one is working on a patch, then that's what needs to be addressed (as you so clearly stated).

brahms’s picture

StatusFileSize
new7.37 KB
Failed: Failed to apply patch.
[ View ]

Here is my attempt to provide a patch for Drupal 7. I took the last D7 patch from comment 166 respecting most of the recommendations from comment 187.

One thing I kept is the strstr comparison between the host part of the request and the proxy exception patterns. I am not able to see why this should be broken. strstr('localhost', 'localhost') returns 'localhost' and so localhost does match localhost. Maybe there has been a mix-up of strpos with strstr in the review?

waddles’s picture

@brahms: sorry to tell you this but that patch is far from ready. You have included code that is commented and haven't resolved several of the issues noted in #187. Also, the accepted patch should provide unit tests so that it can be tested properly using the ATS. In fact, unit tests should be written first.

@Damien Tournaud:
@Crell:
@chx:
You don't seem to realise that most of the people in this thread are from enterprises running a Drupal RELEASE, not CVS. Setting up and maintaining a CVS site behind a proxy is not a trivial task, especially when the expected result is that some things won't work and other things work differently to the version you are actually trying to run (D5/6). Many enterprises are not prepared to pay someone to test their less than perfect code against the production proxy server and most workers leave their proxy server behind when they go home at night. This is a significant issue with significant work required, not a 20 minute re-roll.

@everyone: if you have nothing to say that will progress this to resolution, please don't say anything. Posting a 'subscribe' comment or correcting someone's grammar is pointless. D.o. really needs #34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment - a way for people to subscribe without cluttering the issue with 'subscribe' comments.

What this issue needs is an expert who will see it through to the end. None of us seem to be experts but I am prepared to do what is necessary to get it into D7, with unit tests, all passing the ATS with full support of HTTP and HTTPS (using CONNECT). My only problem is time - I won't be able to start until mid August. If somebody wants it sooner, maybe they should start a Chip-In bounty for it that might attract a D7 expert.

Slim Pickens’s picture

I've probably said before that this should be part of a standard D7 setup. Unfortunately I do not have the skills to create an approved standard patch for consideration.

I work for a school system with at least 1600 schools behind a firewall/authenticated proxy server - and this is just in one state of Australia.

For promoting the use of Drupal around the world, this feature is a no-brainer - it must be done. How hard can it be? Seems like the work has been done - and the argument is over dotting 'i's and crossing 't's.

Come on Dries - throw some resources at it to get it into D7, please!

c960657’s picture

Status:Needs work» Needs review
StatusFileSize
new12 KB
Failed: Failed to apply patch.
[ View ]

New patch for D7 based on the latest patch by brahms.

The patch adds proxy support to the new browser in includes/browser.inc instead (this is supposed to replace the implementation in drupal_http_request(), see #553280: Integrate browser.inc and drupal_http_request()).

I haven't tested the proxy username/password stuff (because my local proxy does not require this).

Damien Tournoud’s picture

@c960657: thanks for working on this.

+++ includes/browser.inc 9 Sep 2009 22:37:08 -0000
@@ -631,37 +631,80 @@ class Browser {
+        elseif (substr($exception, 0, 1) == '.' && substr_compare($hostname, $exception, -strlen($exception)) == 0) {
+          return FALSE;
+        }

The first part is just $exception[0] == '.', and I find the substr_compare() here a little bit cryptic. substr($hostname, -strlen($exception)) == $exception seems easier to understand.

+++ includes/browser.inc 9 Sep 2009 22:37:08 -0000
@@ -631,37 +631,80 @@ class Browser {
+        elseif (filter_var($exception, FILTER_VALIDATE_IP) && $exception == gethostbyname($hostname)) {
+          return FALSE;
+        }

This should probably be FILTER_FLAG_IPV4, because gethostbyname() doesn't support IPV6 yet.

+++ includes/browser.inc 9 Sep 2009 22:37:08 -0000
@@ -685,18 +728,26 @@ class Browser {
+    if ($this->shouldUseProxy($options[CURLOPT_URL])) {
+      $options[CURLOPT_PROXY] = variable_get('proxy_hostname');
+      $options[CURLOPT_PROXYPORT] = variable_get('proxy_port', 8080);
+      if (variable_get('proxy_username')) {
+        $options[CURLOPT_PROXYUSERPWD] = variable_get('proxy_username') . ':' . variable_get('proxy_password');
+      }
+    }

cURL options are persistent. Don't we need a else clause here?

+++ modules/simpletest/tests/browser.test 9 Sep 2009 22:37:09 -0000
@@ -35,18 +35,40 @@ class BrowserTestCase extends DrupalWebT
+    variable_set('proxy_exceptions', implode(',', gethostbynamel('drupal.org')));
+    $this->assertTrue($browser->shouldUseProxy('http://example.com/'), t('Proxy is used for host not in exception list.'));
+    $this->assertFalse($browser->shouldUseProxy('http://drupal.org/'), t('Proxy is not used for host that resolves to an IP address in exception list.'));

Please, try to avoid network lookups during the tests (the secret plan is to allow tests to run in full network isolation one day). You can probably safely assume that localhost resolves to 127.0.0.1.

+++ modules/system/system.admin.inc 9 Sep 2009 22:37:10 -0000
@@ -1461,18 +1461,88 @@ function system_performance_settings() {
+  // Check that an IP address or a valid hostname is specified.
+  if (strlen($form_state['values']['proxy_hostname']) > 0
+      && !filter_var($form_state['values']['proxy_hostname'], FILTER_VALIDATE_IP)
+      && gethostbyname($form_state['values']['proxy_hostname']) == $form_state['values']['proxy_hostname']) {
+    form_set_error('proxy_hostname', t('The proxy host name cannot be found.'));
+  }
+  if (strlen($form_state['values']['proxy_port']) > 0) {
+    $proxy_port = $form_state['values']['proxy_port'];
+    // TCP allows the port to be between 0 and 65535 inclusive
+    if (!is_numeric($proxy_port) || ($proxy_port < 0) || ($proxy_port > 65535)) {
+      form_set_error('proxy_port', t('The proxy port is invalid. It must be a number between 0 and 65535.'));
+    }
+  }

Those should be #element_validate functions of their own element.

+++ modules/system/system.module 9 Sep 2009 22:37:11 -0000
@@ -878,18 +878,26 @@ function system_menu() {
+   $items['admin/config/system/proxy'] = array(
+     'title' => 'Proxy server',
+     'description' => 'Configure how Drupal connects to other websites.',
+     'page callback' => 'drupal_get_form',
+     'page arguments' => array('system_proxy_settings'),
+     'access arguments' => array('administer site configuration'),
+     'file' => 'system.admin.inc',
+   );

There is a small indentation issue here.

This review is powered by Dreditor.

c960657’s picture

StatusFileSize
new12.43 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy-2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Great comments. All points are addressed in this patch.

Damien Tournoud’s picture

Status:Needs review» Needs work

This patch is getting even more awesome by the day ;)

+++ includes/browser.inc 10 Sep 2009 19:23:28 -0000
@@ -631,37 +631,80 @@ class Browser {
+        elseif (filter_var($exception, FILTER_VALIDATE_IP, FILTER_VALIDATE_IP) && $exception == gethostbyname($hostname)) {
+          return FALSE;
+        }

The second parameter should probably be FILTER_FLAG_IPV4.

+++ includes/browser.inc 10 Sep 2009 19:23:28 -0000
@@ -685,18 +728,29 @@ class Browser {
+      $options[CURLOPT_PROXY] = FALSE;

cURL can be a strange beast sometimes. Have you verified that this works?

+++ modules/system/system.admin.inc 10 Sep 2009 19:23:28 -0000
@@ -1461,18 +1461,93 @@ function system_performance_settings() {
+/**
+ * Element validate function for proxy port number.
+ */
+function system_proxy_port_validate($element, &$form_state) {
+  if (strlen($element['#value']) > 0) {
+    // TCP allows the port to be between 0 and 65535 inclusive
+    if (!is_numeric($element['#value']) || ($element['#value'] < 0) || ($element['#value'] > 65535)) {
+      form_set_error('proxy_port', t('The proxy port is invalid. It must be a number between 0 and 65535.'));
+    }
+  }
+}

form_set_error() should be form_error($element) here.

Why not abstracting those element validation a little bit? This is simply a system_port_validate() ;)

I'm on crack. Are you, too?

c960657’s picture

Status:Needs work» Needs review
StatusFileSize
new12.4 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy-3.patch.
[ View ]

cURL can be a strange beast sometimes. Have you verified that this works?

Yes, setting it to FALSE seems sufficient (and not resetting it like in proxy-1.patch does indeed cause trouble).

The other points are fixed.

(BTW I look forward to the day when FAPI will support something like this: '#type' => 'number', '#min' => 0, '#max' => 65535 - and transform it into a nice HTML5 input field <input type="number" min="0" max="65535" /> and of course also do server-side validation :-)

Damien Tournoud’s picture

Status:Needs review» Reviewed & tested by the community

Good, let's get this in ;)

Next stop: make drupal_http_request() use the browser ;)

webchick’s picture

Status:Reviewed & tested by the community» Needs work

This will need a sign-off from Dries, IMO, since this patch has changed significantly since the incarnation where he was on the cusp of committing it. Too bad there was so much jiggering with the version selector, or this likely would've been resolved (and possibly backported) a year ago. Sigh...

I'm not sure of this new approach. It doesn't look like the latest patch actually fixes the problem; just fixes it in the brower.inc which hinges on drupal_http_request() moving over to it. There is quite literally nothing at #553280: Integrate browser.inc and drupal_http_request(), which doesn't give me confidence that we'll end up doing this in time for the end of code slush. And even if we do get a patch over there, we're going to need to talk over the implications of basically forcing core to require cURL (unless I am mistaken about the state of the final browser.inc that made it in).

Couple of minor things:

From a usability perspective, it'd be nice to have a line or two description in hook_help() for this form that would indicate to me as an end-user whether I need to worry about this or whether I can ignore it. It seems very odd to me to include such a 'scary' settings form in core when only 1/10000000 sites will use it, but this passed Dries's sniff test, so that's fine.

+  $form['forward_proxy']['proxy_password'] = array(
+    '#type' => 'textfield',
+    '#title' => t('Password'),
+    '#default_value' => '',
+    '#description' => t('The password used to connect to the proxy server. This is stored as plain text.'),
+  );

Why display it as plain-text as well? That's odd. Shouldn't this be a password field?

+function system_port_validate($element, &$form_state) {
+  if (strlen($element['#value']) > 0) {
+    // TCP allows the port to be between 0 and 65535 inclusive
+    if (!is_numeric($element['#value']) || ($element['#value'] < 0) || ($element['#value'] > 65535)) {
+      form_error($element, t('The port number is invalid. It must be a number between 0 and 65535.'));
+    }
+  }
+}

I'm pretty sure 0 is not a valid proxy port. So probably make this > 1. Also, there should be a period at the end of this comment.

Other than those small things, this looks fine from my perspective.

c960657’s picture

Status:Needs work» Needs review
StatusFileSize
new15.46 KB
Failed: Invalid PHP syntax in modules/simpletest/tests/browser.test.
[ View ]

Why display it as plain-text as well? That's odd. Shouldn't this be a password field?

Changed to '#type' => 'password'. I'm not sure if this is the best way to populate the field: '#attributes' => array('value' => variable_get('proxy_password')) The point is that we want to indicate to the user whether a password is specified or not.

I'm pretty sure 0 is not a valid proxy port.

According to http://en.wikipedia.org/wiki/TCP_and_UDP_port#Technical_details, 0 is a valid port (but probably not much used in practice).

Added a line to hook_help().

There is quite literally nothing at #553280: Integrate browser.inc and drupal_http_request(), which doesn't give me confidence that we'll end up doing this in time for the end of code slush.

I share your concern, though it was initially the goal to get that fixed in time for D7 (see #340283: Abstract SimpleTest browser in to its own object comment #99). I suggest we postpone this patch until #553280: Integrate browser.inc and drupal_http_request() has landed.

roball’s picture

Priority:Normal» Critical

Changing the priority to critical, since the code freeze for D7 already began.

Status:Needs review» Needs work

The last submitted patch failed testing.

silid’s picture

StatusFileSize
new6.66 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy6.14-D6.patch.
[ View ]

I haven't tested this. I applied the patch for 6.13 to 6.14 and rolled a new patch.

EmanueleQuinto’s picture

StatusFileSize
new6.47 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy6.14-D6.dos2unix.patch.
[ View ]

Patch #223 was with DOS carriage return settings...

Same patch after dos2unix attached below.

catch’s picture

Version:6.15» 7.x-dev

The more times this issue gets moved back to 6.x without being resolved in 7.x, the less change it has of ever being fixed.

roball’s picture

@238: I'm pretty sure most users changing a tag while they add a comment may not be aware that this would apply to the whole thread, rather than their actual post. Do you think it is better to open a new ticket for D6 proxy support and keep this one for D7 only?

EmanueleQuinto’s picture

StatusFileSize
new6.47 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch proxy.6.15.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Proxy patch for 6.15 attached.

catch’s picture

Looks like the latest D7 patch here relies on stream wrappers, so yeah a separate D6 issue seems appropriate since there'll be no straight backport possible of the D7 solution.

c960657’s picture

The D7 patch in #223 is no longer relevant. It is based on browser.inc that was backed out (#600032: Back out browser.inc). So I think the approach suggested for D6 is still relevant for HEAD.

RobLoach’s picture

Version:7.x-dev» 8.x-dev
Priority:Critical» Normal
Status:Needs work» Patch (to be ported)

This is a feature for Drupal 8. It's unfortunate people didn't review the numerous Drupal 7 patches that went up.

catch’s picture

Status:Patch (to be ported)» Needs work

There's no code base change between D7 and D8 yet ;)

RobLoach’s picture

Oh, I was talking the Drupal 6 patches they're upload :-P .

stefanhapper’s picture

StatusFileSize
new77.03 KB

Patch provided in #240 works great for Drupal 6.15

To help those who - like me - apply patches manually I am attaching the changed files. Just replace the core files with the ones in the ZIP, clear your cache and set your proxy in site configuration > proxy settings

ryan.nauman’s picture

After applying the patch it was necessary to run the drupal database update script before the Proxy area was added to the Site Configuration area.

Damien Tournoud’s picture

@Rob Loach: all the D7 patches that got posted got reviewed. The issue here is not the lack of review, but the lack of patches to begin with. Posting a Drupal 6.15 patch here helps no one.

Kisama’s picture

Ok, look. That 6.15 patch worked. Now we've had a version increase and it's time to manually patch this into 6.16. What is going to take to get this code merged into the core code so we can move on. It's been almost 6 years now since someone asked for this functionality. What's the hold up?

Crell’s picture

@Kisama: As stated repeatedly in this thread, never. This functionality will never be in any release of Drupal 6, ever. Drupal 6 is feature frozen and has been since the 6.0 release was made. New functionality goes into the development version only. Easily half the posts in this thread are people asking for or demanding Drupal 6 versions, despite it being repeatedly explained that it will never happen. Those posts are the reason this issue never got resolved in Drupal 7, and now we have to wait for Drupal 8.

Repeating: Because people kept demanding a Drupal 6 version of this patch, we will have to wait for Drupal 8 for it. Yes, there is a causal relationship there. Maybe if one of those enterprise users who need it so much spend the time working on the patch properly rather than just demanding free work in ways that violate Drupal's development process this would be resolved by now.

The hold up is someone working on this patch *on the development version of Drupal*. Until/unless that happens, it will never get in. If you want this functionality, that's all you've got to do. Until then, make do with patching core.

roball’s picture

Version:8.x-dev» 7.x-dev

I have created a new thread dedicated to proxy server support for Drupal 6 here: #735420: Drupal 6 proxy server support, so this thread might finally turn into productivity again and leads to a working patch for D7.

Please NO MORE MENTION OF D6 HERE - otherwise some core developers might get angry...

arhak’s picture

@#252 I would preferred to start a clean D7 issue instead, this one is reaching the 300 posts

vvanaparthy’s picture

I am working on a patch to use CURL instead of primitive fsockopen with proxy support. Please be tuned!

glowrocks’s picture

Status:Needs review» Needs work
Issue tags:+Favorite-of-Dries

"Repeating: Because people kept demanding a Drupal 6 version of this patch, we will have to wait for Drupal 8 for it."

In the real world, many of us will have to continue to violate one of Drupal's biggest caveats: don't modify core.

Well, if required functionality isn't in core, we'll have to keep patching.

I hate to see Drupal devolve this way, where standing on "principle" is more important than providing a feature that has been requested for what appears to be 6 years.

And yeah, I'm not a coder, so I can't provide the necessary functionality myself.

What's frustrating is that the fix appears to be somewhat well known, but for obscure reasons it's not making it into core.

cooperaj’s picture

StatusFileSize
new4.43 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-d7a4.patch.
[ View ]

Reading this issue is like some sort of never ending bad dream. Can we please get some sort of organisation in so that backport requests, patches and subscriptions can be moved off to another issue number. Would it be worth closing this one as some bad history and creating a new issue for D7/8?

So I'm not commenting uselessly and contributing to this bad dream please find attached a D7 Alpha 4 patch that I'm using sourced mostly from #231 above. I'll investigate a D8 patch shortly (though I assume it's mostly identical to D7 at this point).

I've removed the UI elements from that patch too as IMHO this is a feature needed by a minority only and should not clutter the UI further. Setting the necessary variables can now be done using settings.php and as such I've added the placeholders to default.settings.php.

Damien Tournoud’s picture

Status:Needs work» Needs review
Issue tags:-Ancient

Nothing happens by magic.

#257 looks like a decent base.

Status:Needs review» Needs work

The last submitted patch, 7881-d7a4.patch, failed testing.

arhak’s picture

@#260
no one said it has to happen magically
also it is pretty obvious why it has been delayed
but you removed what it is NOT a useless tag, which grouped (no longer since you destroyed it) issues from 2007 still opened
(now incidentally bumped with the tagging)

certainly you did the favor of getting ride of a couple of them that should be marked as "won't fix" or "duplicate" a long time ago, but still they are others that do make sense to keep tagged as opened a long time ago and still pending

is there any shame on that?
won't you call "ancient" issues three years old?
if the tag doesn't makes sense to you, why not letting others use it to follow up their interest?

isn't this a community any more?
when did it turned into a dictatorship?

Crell’s picture

"Issues that are old" don't need a tag. You just go back a few pages in any queue and boom, you've got old stuff. The tag adds nothing other than "wah, this is old, why won't someone work on it". That's especially true of "let it end".

Your community vs. dictatorship comment at the end is also out of line. Damien has just as much right to say that the tag you're adding is unnecessary noise as you have to claim that it isn't. In this case, I happen to agree with him.

arhak’s picture

@#263 I just didn't mean to boom anything, just tagging to group them under a common radar, not useful for you, ok, but certainly useful for others, ergo your argument doesn't hold, that's what free tagging use to be for, "free"
lets stop it there, I'll say ok, since now we are really off-topic

Damien Tournoud’s picture

@arhak: you are just unnecessary adding noise. Tagging an issue as old just because it is old doesn't make a lot of sense: you can just order the issues by date and come to exactly the same conclusion.

The amount of time you spent tagging those issues could have been better spent actually *reviewing* them. Over the five or six issues you tagged as "Ancient", I marked two as won't fixed, marked one as a duplicate and reviewed one and marked it as RTBC.

What about doing the same the next time?

Easy task here for example: what about rerolling the patch that failed the test bot, instead of discussing about my "attitude"?

arhak’s picture

I am quite off-topic, I sent you a mail

cooperaj’s picture

StatusFileSize
new4.41 KB
PASSED: [[SimpleTest]]: [MySQL] 20,429 pass(es).
[ View ]

Made changes to the patch format. Git diff seems to do something that the patch god doesn't like.

Edit..
Ah, hidden in a comment on the patch docs page is the chestnut --no-prefix for git diffing. Good advice that :)

arhak’s picture

Status:Needs work» Needs review

hitting the bot

cooperaj’s picture

StatusFileSize
new4.42 KB
PASSED: [[SimpleTest]]: [MySQL] 22,017 pass(es).
[ View ]

Sorry to do this.

After having read though the patch I found that the bit where it adds Proxy authorisation was a load of nonsense I'd not corrected (I don't use a proxy that needs it). I've changed it now so it should work but it's still untested.

nc.anwar’s picture

Issue tags:-Favorite-of-Dries

#8: common.inc_6.patch queued for re-testing.

alekas’s picture

#269: 7881-d7a4.patch queued for re-testing.

dk1844’s picture

Status:Needs work» Needs review

#34: drupal_intranet_proxy_7.x.diff queued for re-testing.

Rob Knight’s picture

For those of you with proxy issues, I've created a module which provides a workaround without needing to patch core modules - the update status proxy module. It's beta code, so I'd appreciate some feedback. This shouldn't distract from the need for a proper fix in core, but it does make it possible to get important module update notifications without patches.

c960657’s picture

Status:Needs review» Needs work
+  if (FALSE == empty($proxy_exceptions)) {

Simply !empty() should be enough.

+    $patterns = explode(",", $proxy_exceptions);

You should use single quotes here.

+      if (strstr($host, $pattern)) {

Doing a substring search seems like an odd thing. If anything, it should do suffix matching. How about allowing the admin to specify a regexp instead? At least it is flexible and allows both suffix and complete string matching. And though the syntax may be bit complex, at least it is wellknown format (compared to anything. we invent ourself).

+        $rv = TRUE;
+        break;
...
+  return $rv;

Just return early.

miouge’s picture

Status:Needs work» Needs review

#220: proxy-3.patch queued for re-testing.

pwolanin’s picture

Status:Needs review» Needs work

code style issues not corrected - likely stale after other changes to this function.

pwolanin’s picture

Status:Needs work» Needs review
StatusFileSize
new2.31 KB
PASSED: [[SimpleTest]]: [MySQL] 23,326 pass(es).
[ View ]

Here's a substantially simplified patch that avoids needless code.

Perhaps someone with a proxy setup would care to test it?

pwolanin’s picture

StatusFileSize
new2.41 KB
PASSED: [[SimpleTest]]: [MySQL] 23,320 pass(es).
[ View ]

oops - that was missing one critical line. Also improved the code comments in default.settings.php.

pwolanin’s picture

StatusFileSize
new2.42 KB
PASSED: [[SimpleTest]]: [MySQL] 23,325 pass(es).
[ View ]

I think the handling is wrong if the original URL has a username/pass. This should fix it.

Also - do we need to urlencode the original URL when it's used as a path?

pwolanin’s picture

Category:feature» task
Status:Needs review» Needs work

Testing with Charles proxy.

While this looks nice and simple, the wrong Host header gets sent.

pwolanin’s picture

Status:Needs work» Needs review
StatusFileSize
new3 KB
PASSED: [[SimpleTest]]: [MySQL] 23,349 pass(es).
[ View ]

This seems to work better.

works with both Charles and Paros as local proxies.

groovehunter’s picture

okay last one #281 worked for me on current 7.x-dev
thx!

roball’s picture

wow, so is there a chance to get in into 7.x?

pinventado’s picture

Issue tags:-Favorite-of-Dries

I'm behind a proxy without authentication so applied the patch on Drupal 7.0-alpha6. When I install a module from a URL, it gives of the following error:

Notice: Undefined variable: fp in drupal_http_request() (line 840 of /var/www/adric/includes/common.inc).
Notice: Undefined variable: errno in drupal_http_request() (line 843 of /var/www/adric/includes/common.inc).
Notice: Undefined variable: errstr in drupal_http_request() (line 844 of /var/www/adric/includes/common.inc).
HTTP error 0 occurred when trying to fetch http://ftp.drupal.org/files/projects/wysiwyg-7.x-2.x-dev.tar.gz.
Unable to retrieve Drupal project from http://ftp.drupal.org/files/projects/wysiwyg-7.x-2.x-dev.tar.gz.

The error refers to the codes that were patched. Any ideas what's wrong? Is there a way to get more specific errors for this?

Thanks!

pwolanin’s picture

Issue tags:+Favorite-of-Dries, +proxy

@pinventado - why did you change the issue tags?

jpsoto’s picture

I found out this patch yesterday and I have just seen the mentioned errors (patch applied to D7 Alpha6).

Using Xdebug, it is clear the issue: no socket is opened (@fscokopen) when the uri['scheme'] is 'proxy'.

I will try to find out a workaround.

However, it would be easier for who knows how worked this patch on previous D7 releases.

Indeed, present code should be not merged into the core yet.

¿May be, the patch should be applied to the HEAD?

jpsoto’s picture

OK, I see ... clearly this patch cannot be applied to the D7 Alpha6, only to the HEAD

pwolanin’s picture

@jpsoto - indeed - we almost never patch against a tag, only against HEAD.

jpsoto’s picture

StatusFileSize
new3.59 KB
PASSED: [[SimpleTest]]: [MySQL] 24,819 pass(es).
[ View ]

Dear friends ...
since some proxies refuse to forward requests with any user-agents, I would like to submit for your consideration a light variation of the last patch, being able to configure the Header User-Agent.

pwolanin’s picture

Status:Needs review» Needs work

The patch doesn't seem to satisfy the use case you lay out. Also , ideally as much as possible of the proxy stuff should be within the case 'proxy':

pwolanin’s picture

Status:Needs work» Needs review
StatusFileSize
new4.22 KB
PASSED: [[SimpleTest]]: [MySQL] 31,490 pass(es).
[ View ]

How about this? By default it leaves the Drupal user agent header, but gives you the option to unset or change it.

jpsoto’s picture

@pwolanin - Thanks for appreciating the suggestion related to the Header User-Agent.

Yes ... , your approach is better.

jpsoto’s picture

Dear friends, ...
I am noting failures when forwarding https urls through a proxy. Result "Bad-Request" is returned.

I will try to make more specific this comment.

Meanwhile, has anybody checked https urls using the scheme 'proxy'?, what is your experience?

Regards

pwolanin’s picture

@jpsoto - I think the code assumes you are not proxing ssl, though it might work

<?php
   
case 'proxy':
     
// Make the socket connection to a proxy server.
     
$socket = 'tcp://' . $proxy_server . ':' . variable_get('proxy_port', 8080);
     
$port = '';
      if (isset(
$uri['port']) && $uri['port'] != 80) {
       
$port = ':' . $uri['port'];
      }
     
// The Host header still needs to match the real request.
     
$options['headers']['Host'] = $uri['host'] . $port;
      break;
?>
jpsoto’s picture

After deeping into the issue, it seems clear.

Code implements RFC-2616 and RFC-2617 (i.e. proxy support for non-SSL).

Unfortunately, there is no support for RFC-2817 yet. Such a support could provoke a moderately heavy rewrite of the patch.

A reference implementation could be this Python recipe
http://code.activestate.com/recipes/456195-urrlib2-opener-for-ssl-proxy-...

See you soon ...

pwolanin’s picture

@jpsoto - this issue has been open since Drupal 4.5 - let's get what we can.

In fact PHP fsockopen() (or at least our use of it) only handles HTTP 1.0 connections, so we need to conform to RFC-1945 and cannot use HTTP 1.1 tricks.

note the code:

  $request = $options['method'] . ' ' . $path . " HTTP/1.0\r\n";

Likely HTTP 1.1 and https proxy support will require use of the curl library and will not be in core until Drupal 8.

jpsoto’s picture

StatusFileSize
new9.04 KB
PASSED: [[SimpleTest]]: [MySQL] 24,827 pass(es).
[ View ]

OK ... I understand.

May be, at present we could try to cover this gap using the function stream_socket_enable_crypto().

Attached you can find a patch with a tentative approach. A moderately heavy writting of the drupal_http_request() has been needed.

I have just carried out a few preliminary tests to verify requests without proxy are still working.

Unfortunately, after this weekend I cannot verify requests by a (corporative) proxy.

Therefore, please, consider this patch as a tentative proof-of-concept patch and ... please check it up within your environment (if possible).

See you next days ...

UPDATE 22/sep. Patch is not working properly. Please, do not use; it will be improved.

pwolanin’s picture

@jpsoto - the patch in #297 doesn't make any sense to me. It might work in limited special applications, but would not be seamless. Callers are not passing in the now parameter and you we DO NOT support HTTP 1.1 responses, which may include chunked encoding. There is no point in the patch since a special application would likely use the curl functions or something else instead of just getting the connection passed back.

Basically, if we get any support for proxies, we are not going to support https proxying in Drupal 7.

Can someone please review #291?

jpsoto’s picture

@pwolanin - After reading this long issue, I think without support for https proxying the patch #291 could be not nominated to be applied into the core. Https proxying is not an exotic requirement . Without https support, usefulness would be heavily limited; a selected example (among many) could be Google OpenID which requires https access:
https://www.google.com/accounts/o8/id

Of course, ... the main goal has to be getting #291 into the core. Extremely agree. I will support it.

Without detriment to the main goal, the tentative patch #297 demonstrates an approach to achieve https proxying. Yes, ... an approach, untested by now, but an approach for D7 (may be never D8 becomes real). Because, there is a clear fact: D7 uses the PHP stream functions, not curl functions
http://www.php.net/manual/en/ref.stream.php
I will try to improve the tentative patch #297.

Answering your final question, ... yes, I have tested the patch #291. I think patch #291 is working.

chx’s picture

Hm, i see the question but not the answer. So remind me, why are we reimplementing cURL?

pwolanin’s picture

@chx - many PHP installs are not built with cURL, so we'd need to add it to requirements. Right now we only require it for Testing module.

I'm tempted to say it's too late for 7 to change this.

jpsoto’s picture

I understand the prefer solution for SSL proxy support is based on the curl library, and likely delayed to Drupal 8.

However, I would like to demonstrate SSL proxy support is feasible without the curl library in D7. I have just submitted a patch, opening a new issue (#924498: Proxy https support for drupal_http_request()) to not interfere in this issue.

pwolanin’s picture

Status:Needs review» Reviewed & tested by the community

Based on #299 (jpsoto verified it works, in addition to my verification) and discussion and review in IRC with jhodgdon I think the patch in #291 (NOT the last patch in #297) is ready to mark RTBC.

jpsoto’s picture

I agree, patch at #291 works ...

I back to commit it into Drupal core. Proxy support is a real need to allow Drupal sites in intranets, behind corporative proxies. Indeed, a big ecosystem.

Patch #297 was a tentative approach to add SSL proxy support. To not interfere in this issue I decide to create a separate issue to demonstrate SSL proxy support without curl library: #924498: Proxy https support for drupal_http_request().

pwolanin’s picture

#291: 7881-proxy-please-291.patch queued for re-testing.

Dries’s picture

I'd prefer to see a version based on CURL. I think it could still go in into Drupal 7 -- it is a transparent addition.

pwolanin’s picture

@Dries - how would using curl be transparent? It would be a rewrite of drupal_http_request() to use curl instead of sockets and adding curl as a new requirement?

Dave Reid’s picture

That is just *not* possible in D7.

pwolanin’s picture

@Dave Reid - *what* is not possible? Adding the use of cURL?

jpsoto’s picture

Regarding of the proxy support, I am not able to understand what real need entails to introduce cURL: a net dependence for many PHP distributions and then, a messy dependence for Drupal.

This patch has proved to work using low-level functions. Even more, the fork #924498: Proxy https support for drupal_http_request() proves https proxy support using low-level functions. No cURL is needed, at all.

If everybody agree proxy support is a clear Drupal's gap, then, ... what is the doubt?

In all modesty, I back to commit this patch into Drupal core, and later to upgrade it for https proxy support.

GAMe’s picture

Hi all,

please forgive my ignorance but could this not be made as a seperate module? sadly im not a PHP dev so I cant comment on the complexity of this beast but obviously this is a long standing issue for many people.

but great work on what has been done so far, could anyone else comment on if this patch works correctly for D6.20.

Thanks all!

pwolanin’s picture

@GAMe - no this could not be made a module - it requires changes to the core internals.

GAMe’s picture

I figured this was likely to be the case as this has not been done already but thanks for the responce back :-)

jrbeeman’s picture

I agree that it'd be great to see this done in cURL. Maybe a solution could be to use cURL if it's there, if not fall back to the way we've currently got it...?

pwolanin’s picture

@jrbeeman - I think that has to be Drupal 8 material - basically we'd need to implement a more OO-based approach where we can have a strategy pattern, such as Drupal 7 has for the database driver.

jpsoto’s picture

Obviously, this old issue and its recent fork #924498: Proxy https support for drupal_http_request() are ssssstuck -->|||||

I am thinking about an alternative way.

Maybe, a suitable approach is to implement a new alter-type hook: a hook_http_request_alter() which would allow to override the default implementation of drupal_http_request(). A good reference could be the hook_custom_theme().

Advantages??

On the one hand, a solution for this old issue (a real advantage). On the other hand, such an approach would circumvent difficulties and hard decisions on the Drupal core (i.e. cURL and so on)

Please, I would appreciate your comments ...

Dries’s picture

+++ includes/common.inc 18 Sep 2010 11:21:55 -0000
@@ -767,7 +767,7 @@ function drupal_access_denied() {
+function drupal_http_request($url, array $options = array(), $fp_in = NULL) {

- What does $fp_in mean? Not very descriptive, and not documented. It doesn't look like we set/pass $fp_in anywhere in the code, either. Feels like a fishy parameter so I'd like to better understand that. Thanks!

- Do we have any data on how many PHP installations might, or might not have CURL installed? (Don't spend much time looking. I'm just curious.)

jpsoto’s picture

@Dries,
likely you have got this code excerpt from a patch initially submitted by me in this issue. Later, I opened a different (but related) issue to not interfere, because I was convinced SSL support is feasible without cURL support and without waiting for D8.

Please, check the patch in the issue #924498: Proxy https support for drupal_http_request(), there is a short description of the mentioned argument.

Following I reproduce it together with code excerpts to explain it

/*
* ...
* @param fp_in
*   An optional file pointer, if the socket is provided externally
* ...
*/
function drupal_http_request($url, array $options = array(), $fp_in = NULL) {
[...]
  // As described by RFC-2817
  switch ($uri['scheme']) {
    case 'proxy_https':
        $options_connect = array(
            'headers'  => array(),
            'method'   => 'CONNECT',
            'protocol' => 'HTTP/1.0'
        );
        $options_connect['headers']['Host']
              = $options['headers']['Host'];
        $options_connect['headers']['User-Agent']
              = $options['headers']['User-Agent'];
        $options_connect['headers']['Proxy-Authorization']
              = $options['headers']['Proxy-Authorization'];
        if (!($result_connect = drupal_http_request($url, $options_connect, $fp))) {
            ($fp_in) ? TRUE : fclose($fp);
            return $result_connect;
        }

        stream_socket_enable_crypto($fp, TRUE, STREAM_CRYPTO_METHOD_SSLv23_CLIENT);
      break;
  }

[...]

Please, note the proposed SSL support for drupal_http_request() requires an embedded call for the own drupal_http_request() to carried out the CONNECT method, with a notable remark: using the same socket.

This because the https requests have two different stages, first a CONNECT method and then, the usual methods after enabling crypto. See RFC-2817.

Please, note every call for drupal_http_request() is oriented to manage only one HTTP method, this could explain why I have to introduce such an argument (fp_in) to manage the embedded CONNECT using the same socket.

Regarding of how many PHP distributions might have (or not) cURL installed, I have only contributed my knowledge on the PHP packaged within Debian and Ubuntu distributions. Such distributions have not installed.

c960657’s picture

Maybe, a suitable approach is to implement a new alter-type hook: a hook_http_request_alter() which would allow to override the default implementation of drupal_http_request().

FWIW, this has been proposed in #786074: Allow hooks for drupal_http_request() request and responses.

pwolanin’s picture

StatusFileSize
new4.22 KB
PASSED: [[SimpleTest]]: [MySQL] 31,553 pass(es).
[ View ]

This is an unaltered re-roll (except for offset) of the patch in #291. That's the patch that's marked RTBC.

jpsoto’s picture

@c960657
I beg your pardon for overlooking the mentioned feature request, and your proposed patch.

I am strongly interested on testing it.

The presentation of #786074: Allow hooks for drupal_http_request() request and responses describes clearly many benefits to introduce such hooks.

Maybe, the more sense solution include two actions:

  • improve the default implementation of drupal_http_request(), i.e. including proxy support
  • allow to override it for advanced topics (your suggested hooks)
  • SangersDrupalDude’s picture

    These patches caused me all sorts of problems, they assume port 80 and tend to break post requests, if you have a proxy and wish to use apache-solr, the correct syntax is:

      if ($content_length > 0 || $method == 'POST' || $method == 'PUT') {
        $request = $method . " " . $uri[scheme] . "://" . $host . $path . " HTTP/1.1\r\n";
        $request .= $defaults['Content-Length'];
        $request .= "$data\r\n";
      }
      else{
        $request = $method . " ". $uri['scheme'] . "://" . $host . $path . " HTTP/1.1\r\n";
        $request .= "\r\n\r\n";
        $request .= $data;
      }
    pwolanin’s picture

    @SangersDrupalDude - I don't understand the problem you are having. Also, we can't use HTTP/1.1 in the request, since drupal only handle HTTP/1.0 responses.

    Can you please provide more details as to how to reproduce your problem or post an actual patch?

    Raf’s picture

    StatusFileSize
    new799 bytes
    FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy_patch-system.module.patch.
    [ View ]
    new3.21 KB
    FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy_patch-system.admin_.inc_.patch.
    [ View ]
    new2.46 KB
    FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in proxy_patch-common.inc__0.patch.
    [ View ]

    Got noooooooooooooo idea how to make Drupal-complient patches, but after going through this thread, finding the 6.14 one, noticing it didn't work on my 6.20 site and applying the changes manually, I created these three patches (one for each file that's changed). They're probably not according to Drupal guidelines, but they do add in proxy support for Drupal 6.20.

    It's tested on a Pressflow site (6.20), but the code in the 6.14 patch and the one in the Pressflow site were the same, so it should work under regular 6.20 as well.

    Status:Reviewed & tested by the community» Needs work

    The last submitted patch, proxy_patch-system.module.patch, failed testing.

    tstoeckler’s picture

    For information on creating patches see http://drupal.org/patch/create.

    pwolanin’s picture

    Status:Needs work» Reviewed & tested by the community
    StatusFileSize
    new4.22 KB
    FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-proxy-please-327.patch.
    [ View ]

    @Raf - please don't derail this issue. We are trying to resolve it for Drupal 7 only at this point.

    re-roll of #320, no changes. If anyone has functional issues with this patch, please post your steps to reproduce.

    Raf’s picture

    This issue's been going on since 2004 (!). Proxy settings are mostly useful for enterprises. These same enterprises prefer to use Drupal 6 over Drupal 7 for now, since it's been thoroughly tested and stable, while Drupal 7's just recently been released. Because of that -- and seeing as this issue's been going on from even before Drupal 6, I don't see why we should ignore all other releases and fix this for a version the target audience won't use just yet, leaving them with no real solution until Drupal 7's mature enough to adapt.

    So in other words: I'll fix it for 6.20, whether or not you want it to be D7 only. I see way more reasons to make it 6.20-compatible first than to make it 7-compatible first. If I'm not allowed to try to give a hand in making this thing work for everybody, then jeez louis, sorry for trying to help!

    pwolanin’s picture

    @Raf - I agree that we should have a good Drupal 6 patch, and I agree that it's enterprises that need it, but I'd like to make sure we have this first. It's possible we could convince David Strauss to put such a change into Pressflow even if it's not officially backported.

    Dave Reid’s picture

    #327: 7881-proxy-please-327.patch queued for re-testing.

    silid’s picture

    @raf - if you want a version for Drupal 6 as many people do, see the seperate issue #735420: Drupal 6 proxy server support.

    Raf’s picture

    @Silid: Thanks. Didn't find it when I searched for a patch (only found this thread). Bit odd that a thread that existed before Drupal 5 doesn't allow a Drupal 6 patch, but I'll go to that thread to help out on it.

    SangersDrupalDude’s picture

    I believe the issue was caused by using jquery above 1.4, I am on 1.6 and the $request .= "\r\n\r\n"; breaks the json requests as it is read as the data by solr, not the data after this?

    davidwhthomas’s picture

    The patch works OK from here, but no HTTPS support?

    e.g for core openid support ( yahoo )

    it's connecting to the proxy and saying 'POST https://open.login.yahooapis.com/openid/op/auth HTTP/1.0'
    which you can't do for https:// ... you need to do 'CONNECT open.login.yahooapis.com HTTP/1.0'

    Maybe the patch can be updated to support HTTPS?

    DT

    EDIT: I actually ended up using this patch http://drupal.org/node/924498#comment-4204694 which works with HTTPS

    rfay’s picture

    Version:7.x-dev» 8.x-dev
    Status:Reviewed & tested by the community» Needs review

    D8 first. Let's get these fixed on D8 and into D7.

    pwolanin’s picture

    @rfay - why back to cnr?

    rfay’s picture

    @pwolanin, I was just assuming that when an issue was changed to another Drupal major version, somebody should at least try it out there (and re-upload the patch to test it on the testbot). Seems reasonable?

    wojtha’s picture

    #327: 7881-proxy-please-327.patch queued for re-testing.

    pwolanin’s picture

    Status:Needs review» Reviewed & tested by the community
    Issue tags:+needs backport to D7
    StatusFileSize
    new4.24 KB
    FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-proxy-please-341.patch. Unable to apply patch. See the log in the details link for more information.
    [ View ]

    I applied this patch to Drupal 8 and re-verified using Paros proxy that I could do update status requests and aggregate a feed via the proxy.

    setting back to RTBC since the code is unchanged. I think this is still appropriate for D7 too.

    jrbeeman’s picture

    Applied, tested and verified @pwolanin's patch in comment #341 to a Drupal 7 site behind a proxy. The site is now able to make proxied HTTP requests! A note on the configuration -- it does not utilize authentication, so I'm unable to verify the username/password-based proxy functionality.

    chateau_dur’s picture

    Hi everyone,

    Just tried the #341 patch but I still can't aggregate my twitter feeds.
    I can't find where I can set my proxy.pac path?
    When I patched common.inc, the lines to define the server where rejected to another file, is it normal?

    Thanks for the help and the effort.

    nvd_ai61’s picture

    #341: 7881-proxy-please-341.patch queued for re-testing.

    I applied the patch in #341 to Drupal 7.2 with no success. I am wondering if I am making some mistake in configuration. I am running nginx on port 80 and drupal on port 8080 both on my localhost. Here is my settings.php:

    $conf['reverse_proxy'] = TRUE;

    # $conf['reverse_proxy_header'] = 'HTTP_X_CLUSTER_CLIENT_IP';

    $conf['reverse_proxy_addresses'] = array('127.0.0.1','localhost', );

    # $conf['omit_vary_cookie'] = TRUE;

    /**
    * External access proxy settings:
    *
    * If your site must access the internet via a web proxy then you can enter
    * the proxy settings here. Currently only basic authentication is supported
    * by using the username and password variables. The proxy_exceptions variable
    * is an array of host names to be accessed directly, not via proxy.
    */
    $conf['proxy_server'] = 'localhost';
    #$conf['proxy_port'] = 80;
    # $conf['proxy_username'] = '';
    # $conf['proxy_password'] = '';
    # $conf['proxy_exceptions'] = array('127.0.0.1', 'localhost');

    does anyone know if this settings is correct based on the information above?

    chateau_dur’s picture

    Have you modified anything else in the file?

    If not, could you send me your common.inc file, I could test it on my website after changing the proxy settings.
    I'd like to test on my own but I can't seem to be able to patch my file... no idea why and it's getting on my nerves.

    Thanks, here's a temporary email address you can use if you like : bi1311252078erv@mail-temporaire.fr

    pwolanin’s picture

    @nvd_ai61 - those settings don't make much sense - do you have nginx set up to proxy to external sites?

    Normally nginx is configured as a load-balancer and reverse proxy, not a forward proxy.

    chateau_dur’s picture

    Does this patch work with 7.4? I get an error right from the beginning.

    pwolanin’s picture

    The patch works fine for me against 7.x HEAD. Use patch -p1

    patching file includes/common.inc
    Hunk #4 succeeded at 1052 (offset 2 lines).
    patching file sites/default/default.settings.php
    pwolanin’s picture

    #327: 7881-proxy-please-327.patch queued for re-testing.

    chateau_dur’s picture

    Hi again,

    Ok I finally managed to install the patch, thanks.

    Problem is, I have a new error in the aggregator module.
    I get a "0 php_network_getaddresses: getaddrinfo failed: Name or service not known". Used to get an "Error 400" before.

    I've set up my proxy in the settings.php file as follows:
    $conf['proxy_server'] = 'http://wwwcache.myproxy.com';
    $conf['proxy_port'] = 8080;
    $conf['proxy_username'] = '';
    $conf['proxy_password'] = '';
    $conf['proxy_exceptions'] = array('127.0.0.1', 'localhost');

    Am I missing something?

    Some help would be welcome again if you don't mind :) I don't know much about proxies but I know mine doesn't require authentication.

    Thanks again!

    xjm’s picture

    Tagging issues not yet using summary template.

    pveltsos’s picture

    Subscribing....

    Patched worked fine on 7.7

    Reporting that the patch is no longer working on 7.8
    Patch applied successfully to setttings.php but *not* to includes/common.inc

    pveltsos’s picture

    Did you verify the port for your proxy (8080)?
    Did you try removing the "http://" from your poxy_server
    What about leaving the # sign in front of proxy_username, proxy_password and proxy_exceptions if you don't need them?

    chateau_dur’s picture

    I tried commenting what I didn't use, i tried removing the http://, using single quotes and not on the port, adding the port to the URL, nothing's working.

    I'm really desperate :( I just don't know what to do.

    Am I missing something?
    1- run the patch
    2- fill in the proxy details in default.settings.php and settings.php
    3- clear the site cache
    4- check for updates/run the aggregator and see if it works

    Is it correct?

    Raf’s picture

    The patch I used (which, admittedly, is a bit old. Used the patch for D6.15 and adapted it for D6.19 or 6.20, some time ago), required me to install the patch, flush caches (as it adds a new menu item), then go to the proxy settings menu (something like system -> proxy), then filling in the proxy address + port + possible other settings there. I don't think I've touched settings.php (unless the patch did, but then that's part of applying the patch)

    Caligan’s picture

    Issue summary posted.

    pwolanin’s picture

    @pveltsos I just checked and the patch still applies for me to 7 and 8 with minor offset.

    sun’s picture

    Status:Reviewed & tested by the community» Needs work
    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +  // Proxy setup - normal sites don't need a proxy.

    Let's drop everything after the hyphen here, please, it only confuses, because you make an assumption about what a "normal" site might be, or not.

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +  if ($proxy_server && _drupal_http_use_proxy($uri['host'])) {

    Would actually be nice to have a short inline comment explaining what that second part of the condition and helper function is supposed to check and do -- right now, I've to follow the call stack to figure it out.

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +    // Since the url is passed as the path, we won't use the parsed query.
    +    unset($uri['query']);
    +    $uri['path'] = $url;

    1) s/url/URL/

    2) I do not understand this comment, and why the query parameters are dropped here.

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +    // Set the scheme so we open a socket to the proxy server.
    +    $uri['scheme'] = 'proxy';
    ...
       switch ($uri['scheme']) {
    +    case 'proxy':
    +      // Make the socket connection to a proxy server.
    +      $socket = 'tcp://' . $proxy_server . ':' . variable_get('proxy_port', 8080);

    Why do we set the scheme to "proxy" if we use "tcp" as scheme afterwards?

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +    // Some proxies reject requests with any User-Agent headers, while others
    +    // require a specific one.
    +    $proxy_user_agent = variable_get('proxy_user_agent', '');
    +    // The default value matches neither condition.
    +    if ($proxy_user_agent === NULL) {
    +      unset($options['headers']['User-Agent']);
    +    }
    +    elseif ($proxy_user_agent) {
    +      $options['headers']['User-Agent'] = $proxy_user_agent;
    +    }

    If I get this right, then we're always unsetting the user-agent by default -- unless proxy_user_agent has been defined in settings.php. Thus, I think this code can be heavily simplified.

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +      $port = '';
    +      if (isset($uri['port']) && $uri['port'] != 80) {
    +        $port = ':' . $uri['port'];
    +      }
    +      // The Host header still needs to match the real request.
    +      $options['headers']['Host'] = $uri['host'] . $port;

    We can set 'Host' to $uri['host'], and move the condition after that, skip the $port variable, and just simply conditionally append the 'port' if necessary.

    +++ b/includes/common.inc
    @@ -1017,6 +1050,18 @@ function drupal_http_request($url, array $options = array()) {
    +  $proxy_exceptions = variable_get('proxy_exceptions', array('localhost', '127.0.0.1'));

    +++ b/sites/default/default.settings.php
    @@ -442,3 +442,18 @@ ini_set('session.cookie_lifetime', 2000000);
    + * by using the username and password variables. The proxy_exceptions variable
    + * is an array of host names to be accessed directly, not via proxy.
    ...
    +# $conf['proxy_exceptions'] = array('127.0.0.1', 'localhost');

    Shouldn't the proxy exceptions also contain $GLOBALS['base_url'] or something?

    +++ b/sites/default/default.settings.php
    @@ -442,3 +442,18 @@ ini_set('session.cookie_lifetime', 2000000);
    + * If your site must access the internet via a web proxy then you can enter

    s/internet/Internet/ if I'm not mistaken.

    6 days to next Drupal core point release.

    gwynnebaer’s picture

    Status:Needs work» Patch (to be ported)
    StatusFileSize
    new4.29 KB
    FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-proxy_0.patch. Unable to apply patch. See the log in the details link for more information.
    [ View ]

    @sun:
    I made the comment changes (cleanup, additional comments) that I could reasonably make.

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +    // Since the url is passed as the path, we won't use the parsed query.
    +    unset($uri['query']);
    +    $uri['path'] = $url;

    Most cache servers don't cache any URI with a query string attached, but I agree that it looks like required information would be lost here, so I think this is a bug.

    +++ b/includes/common.inc
    @@ -789,10 +787,50 @@ function drupal_http_request($url, array $options = array()) {
    +    // Set the scheme so we open a socket to the proxy server.
    +    $uri['scheme'] = 'proxy';
    ...
       switch ($uri['scheme']) {
    +    case 'proxy':
    +      // Make the socket connection to a proxy server.
    +      $socket = 'tcp://' . $proxy_server . ':' . variable_get('proxy_port', 8080);

    The scheme 'proxy' here really means "use tcp:// with additional parameters." This could be rewritten to make all methods use the same logic, but I find this implementation easier to read.

    Re: User-Agent logic, I could only improve the logic by one line, so I left it as-is.
    Re: 'Host', I followed your lead and simplified the logic per other examples in common.inc.
    Re: proxy_exceptions, I think what should be excluded needs to be $_SERVER['SERVER_NAME'] or similar. $GLOBALS['site_url'] contains the scheme, etc, but proxy_exceptions need to be bare host names/IPs.

    chx’s picture

    Status:Patch (to be ported)» Closed (won't fix)

    Add a pluggalbe browser to core, have a basic implementation from drupal_http_request, add curl from simpletest (there's an issue for that already), expose curl option additions into a hook, provide a contrib to do this. It's not core's responsibility to reimplement curl in userspace nor it is the role of core to have interface for all the eight bazillion CURLOPT.

    Aeternum’s picture

    #327 confirmed to apply cleanly and work on 7.8

    kenorb’s picture

    Patch #320 works great for me, thank you.

    SangersDrupalDude’s picture

    the 1.1 was wrong, should be 1.0, didn't cause an issue with squid2 proxy, but needed fixing with squid3 proxy

    Patrizio’s picture

    StatusFileSize
    new16.18 KB
    PASSED: [[SimpleTest]]: [MySQL] 36,261 pass(es).
    [ View ]

    Here it is my backport patch for d6
    Apply on commin.inc

    z-buffer’s picture

    After applying this patch "/**" is missing in common.inc, the result is:

    ...
    * Helper function to determine message body length of the HTTP message
    ...

    and must be:

    ...
    /**
    * Helper function to determine message body length of the HTTP message
    ...
    pwolanin’s picture

    Status:Closed (won't fix)» Needs work

    @chx - wow I never noticed this got closed, I thought it was committed.

    Given that core (especially 7.x) uses drupal_http_request for everything, asserting the curl is the answer is not reasonable.

    denix’s picture

    There is a "Following" link at the top of issues so you can subscribe to the post without flood the issue.

    If you missed it because it is unclear what a green "follow" button means, you can comment here #1376380: "Following" button purpose and use may be unclear

    pwolanin’s picture

    Assigned:Unassigned» Dries

    assigning to Dries, since that's what webchick suggests.

    sun's last review is basically asking for some improved code comments - I don't think there is any problem with the code itself.

    Pol’s picture

    People looking for a patch for Drupal 6.25: http://drupal.org/node/735420#comment-5724654

    Dries’s picture

    I'm still ok with this going in.

    Just wondering if there is a Symfony2 component that we could or should leverage instead of building our own.

    Any thoughts on that?

    pwolanin’s picture

    @Dries - the main goal for this issue was a simple implementation that could be used at least in D7 also (well, or originally, 6, 5, 4.7. 4.6, or 4.5!)

    Certainly, D8 may evolve beyond this in another issue, but the for you the question was whether this should go in based on this patch which is back-portable to D7.

    devonwarren’s picture

    Status:Needs work» Needs review

    #341: 7881-proxy-please-341.patch queued for re-testing.

    mikeytown2’s picture

    StatusFileSize
    new4.11 KB
    PASSED: [[SimpleTest]]: [MySQL] 36,302 pass(es).
    [ View ]

    re-roll of #370. I have no good way to test the functionally of this; I'm mainly interested in getting this working for #1320172: Bring in proxy support.

    denix’s picture

    RobLoach’s picture

    Buzy and Buzz handle external requests via Symfony components. Not entirely what this issue is attempting to solve, but worth mentioning here.

    pwolanin’s picture

    @Rob - see above. Try to get it RTBC now so it can be backported to 7.

    mikeytown2’s picture

    StatusFileSize
    new4.89 KB
    PASSED: [[SimpleTest]]: [MySQL] 36,300 pass(es).
    [ View ]

    Above patch (#384) forgot to have the default headers move higher up. Added in more comments and better explained why unset($uri['query']) is used.

    chx’s picture

    I am still not OK with this going in! Can we close this and do #64866: Pluggable architecture for drupal_http_request() and or re-commit #340283: Abstract SimpleTest browser in to its own object ? Why proxies? Why are we reimplementing cURL piecemeal in userspace? This is not a good idea. I am not buying the "php is not built with curl" option -- if ypu can do a proxy you can do your own PHP.

    pwolanin’s picture

    @chx - this is a pretty trivial mount of code for a feature that's long been missing. Yes for Drupal 8 let's then proceed to rip it out if something better gets into core.

    chx’s picture

    I am but one voice. I have been overridden by core committers more than once.

    sylus’s picture

    I really think we need to commit a working solution to Drupal 7 as soon as possible. Many government sites are starting to jump on the Drupal bandwagon and use such distributions as Open Public etc.

    Without this patch I am assuming such Distributions (Apps) are unusable which would mean a lot less government adoption. At the very least questions as to why we can't support a proxy setup.

    wroxbox’s picture

    Our client has at the moment a new server infrastructure were the patch in #388 is the only solution to get drupal working correct inside the firewalls and proxies. Patch is tested and working as supposed. +1 to get it into core asap!

    sylus’s picture

    Status:Needs work» Needs review
    StatusFileSize
    new996 bytes
    FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-7881-394-2.patch. Unable to apply patch. See the log in the details link for more information.
    [ View ]
    new3.89 KB
    FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-7881-394-1.patch. Unable to apply patch. See the log in the details link for more information.
    [ View ]

    I had to reroll #388 as it would not work with drush make. Though could have been a problem on my part.

    Below are 2 git patches one for common.inc and the other settings.php. (Drupal 7.14)

    Fails testing on Drupal 8 as patch is meant for Drupal 7.14 (Verified and tested with Drush Make)

    Status:Needs review» Needs work

    The last submitted patch, drupal-7881-394-2.patch, failed testing.

    Vincenzo’s picture

    Status:Needs review» Needs work

    That's exactly what I've been needing these days. I haven't tested it yet, so I have a question: if the original URI I have to request is over HTTPS, is it going to be able to handle that via the proxy?

    chx’s picture

    Status:Needs work» Reviewed & tested by the community

    Meh. It's easier to commit #388 than clean up this mess of an issue. I could easily delete half of the comments here. People think core is contrib, meh, go with it,like I care. Before you commit consider how bloated common.inc already is. This might or might not matter. But , no matter what it is just bloat. It's utterly wrong to reimplement cURL in userspace but as this issue testifies people so do not care so I do not care either.

    effulgentsia’s picture

    StatusFileSize
    new5.09 KB
    PASSED: [[SimpleTest]]: [MySQL] 36,983 pass(es).
    [ View ]

    #388 doesn't apply any more. This is a reroll. Additionally, I removed the "Proxy setup" code comment since it seemed redundant with the code comment right below it, and I added 'proxy_user_agent' to default.settings.php.

    Trivial changes, so leaving at RTBC.

    effulgentsia’s picture

    I won't object to #398 being committed, but I think #1664784: drupal_http_request() has problems, so allow it to be overridden is a better approach. There's no need for us to keep plugging holes in our outdated drupal_http_request() implementation when more robust libraries exist.

    pwolanin’s picture

    @effulgensia - as before, getting this into D8 as-is would be useful as a basis for backport to D7. Obviously we will want to improve the http request offerings in D8, especially as the plugin system somes in to place.

    Dries’s picture

    Version:8.x-dev» 7.x-dev
    Status:Reviewed & tested by the community» Patch (to be ported)

    I committed this to 8.x.

    Next steps:

    1) Backport to Drupal 7
    2) Improve the implementation in Drupal 8

    Let's start with 1, and than go back to 2.

    pwolanin’s picture

    StatusFileSize
    new630 bytes
    FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 7881-402.patch. Unable to apply patch. See the log in the details link for more information.
    [ View ]

    a note for the D8 changelog?

    Dries’s picture

    Committed the CHANGELOG update to 8.x. Thanks!

    gwynnebaer’s picture

    Excellent news, Dries. The 20th oldest open issue with Drupal is moving forward again. Much appreciated. We are heavy users of this feature and can provide regression testing for 7.x if needed.

    mikeytown2’s picture

    Status:Patch (to be ported)» Needs review
    StatusFileSize
    new4.87 KB
    PASSED: [[SimpleTest]]: [MySQL] 39,251 pass(es).
    [ View ]

    Rolling #394 in one as this is for D7 and setting to needs review for testbot.

    mikeytown2’s picture

    StatusFileSize
    new5.06 KB
    PASSED: [[SimpleTest]]: [MySQL] 39,249 pass(es).
    [ View ]

    This patch is the one above with the trivial changes made in #398 merged in.

    Pages