Edit report at https://bugs.php.net/bug.php?id=69292&edit=1

 ID:                 69292
 Updated by:         [email protected]
 Reported by:        scott at perturb dot org
 Summary:            Download links are not wget compatible
-Status:             Open
+Status:             Wont fix
 Type:               Bug
 Package:            Website problem
 Operating System:   All
 PHP Version:        Irrelevant
 Block user comment: N
 Private report:     N



Previous Comments:
------------------------------------------------------------------------
[2015-03-25 22:32:05] scott at perturb dot org

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

------------------------------------------------------------------------
[2015-03-25 15:23:31] [email protected]

> 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] [email protected]

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.

------------------------------------------------------------------------


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

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to