Bug #69292 [Opn]: Download links are not wget compatible
| From: | scott at perturb dot org | Date: | Wed, 25 Mar 2015 22:32:05 +0000 |
| Subject: | Bug #69292 [Opn]: Download links are not wget compatible | ||
| References: | 1 | Groups: | php.webmaster |
| Request: | Send a blank email to php-webmaster+get-20977@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=69292&edit=1
ID: 69292
User updated by: scott at perturb dot org
Reported by: scott at perturb dot org
Summary: Download links are not wget compatible
Status: Open
Type: Bug
Package: Website problem
Operating System: All
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
I went ahead and setup my own mirror, and checked out web-php from Github to try tackling this
myself. I think I got it working, and created a pull-request here:
https://github.com/php/web-php/pull/65
Previous Comments:
------------------------------------------------------------------------
[2015-03-25 15:23:31] cmb@php.net
> Does wget *always* use the last component of the url for its
> filename, or can that be fixed somehow?
wget has an --output-document option[1], which should be usable in
this case.
[1] <http://www.gnu.org/software/wget/manual/wget.html#Download-Options>
------------------------------------------------------------------------
[2015-03-25 14:34:19] bjori@php.net
scott: The location of the binary is "implementation detail", which is why we have php in
front of it to verify.
Reordering the components in the url would break boatload of scripts out there, so thats hardly a
realistic option.
Does wget *always* use the last component of the url for its filename, or can that be fixed somehow?
------------------------------------------------------------------------
[2015-03-25 00:01:12] scott at perturb dot org
Looking at the code in do-download.inc, we're not doing anything before we send the
status_header(302) and then give them the real URL. I assumed we were logging the hit or something
like that, thus the download needed to hit PHP.
Since ALL we're doing is a redirect to the tar file, is there a reason the download links
can't be directly to the file on the file system, and not be handled by PHP?
------------------------------------------------------------------------
[2015-03-24 23:48:35] scott at perturb dot org
It's more of an annoyance than a bug. I've worked around it in the past, using the method
you describe. Or even more simply:
wget http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror
-o /tmp/php.tar.bz2
But I *always* forget the first time, and have to repeat it with the work around. It would be nice
if it "just worked (tm)". Someone had the idea of making the download links wget
compatible, because of the comment in the file:
https://github.com/php/web-php/blob/master/error.php#L136
If we just re-ordered the elements in the download link, it would be wget compatible with minimal
changes.
------------------------------------------------------------------------
[2015-03-24 23:29:30] cmb@php.net
In my opinion that is not a bug, but rather something that might be
improved, if at all -- what's wrong with something like:
FILE=php-5.3.29.tar.bz2;\
wget http://br1.php.net/get/$FILE/from/this/mirror;\
mv mirror $FILE
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69292
--
Edit this bug report at https://bugs.php.net/bug.php?id=69292&edit=1