|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67540 blocking Drupal?
Submitted: 2014-06-30 00:14 UTC Modified: 2014-07-05 04:15 UTC
From: php dot net dot e at salvisberg dot com Assigned:
Status: Not a bug Package: Website problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
 [2014-06-30 00:14 UTC] php dot net dot e at salvisberg dot com
A Drupal module that I'm helping to maintain tries to download the following file:

I have no trouble downloading it using my web browser, but a user reports in that the request...

GET /repository/pear/packages/Mail_mimeDecode/trunk/Mail/mimeDecode.php HTTP/1.0
User-Agent: Drupal (+

... fails with an HTTP forbidden notice.

Indeed, I can easily reproduce that with wget (see Test script). Are you blocking the "Drupal" user agent? Why?

Test script:
# wget --user-agent=Drupal

Expected result:
--2014-06-30 02:06:43--
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 39143 (38K) [text/plain]
Saving to: `mimeDecode.php'

100%[=================================================================================================>] 39,143      --.-K/s   in 0.01s

2014-06-30 02:06:43 (2.69 MB/s) - `mimeDecode.php' saved [39143/39143]

Actual result:
--2014-06-30 02:01:51--
Connecting to||:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2014-06-30 02:01:51 ERROR 403: Forbidden.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-06-30 05:27 UTC]
-Status: Open +Status: Not a bug
 [2014-06-30 05:27 UTC]
I do indeed recall an issue where we had to block drupal installation from ddosin our svn repository.

It is clearly not cool on your part to be abusing our repository like this - and its not very smart either, as a svn repository is not somewhere you should be sending your production users.

Please use the normal download mechanism offered.
 [2014-07-04 21:19 UTC] php dot net dot e at salvisberg dot com
Thank you for your reply and comments. I'm sorry if we have caused you grief -- this was surely a bug and not intentional. I'm not sure why you call it "abusing" though.

One Drupal module that implements a mechanism to download from your svn repository is There may be others besides it, and I don't know whether this is the one that ran away, but it's the one we were using.

I see your point about downloading from the svn trunk. I guess, the original developer tried to automate retrieving the dependencies to make it as easy as possible to get up and running quickly without having to deal with pear install and having to wrestle with getting the dependencies to where his module can find them.

In the case of Mail_mimeDecode, downloading from the trunk is probably appropriate though, because there is no current branch / release package.
 [2014-07-04 22:46 UTC]
it is still a bad practice, because there is no promise that we won remove/rename that file or change it's api in a way that it will be incompatible with the caller.
so I fail to see why couldn't your friend just put that script into his package/app?
btw. if anybody interested in the original reason for blacklisting drupal from
now they are using our json api to fetch the signatures:
 [2014-07-04 23:34 UTC] php dot net dot e at salvisberg dot com
Thank you for the links! Since the issue has been identified and resolved, is there any chance that you could lift the ban?
contains a "BSD license style" license. does not allow uploading content that is not under "GPL version 2 or later" (see

The trunk version of mimeDecode.php is 8 months old, the one on GitHub 3 years, and the PEAR package 3.5 years. Downloading the trunk version seems to be the only viable option, even at the risks that you mention.
 [2014-07-05 04:15 UTC]
You are severely misunderstanding the argument from - and if you weren't then you were actually breaking the license by downloading it like this "on-demand".

That same FAQ even states that BSD license is OK.

We will not be removing this block as it is in your best interest so we will continue to protect you from doing bad mistakes.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat May 21 22:03:33 2022 UTC