If you wish to add that as a comment, you must do so using bugs.php.net It does not support email.
-Hannes On Wed, Mar 25, 2015 at 8:23 AM, <c...@php.net> wrote: > Edit report at https://bugs.php.net/bug.php?id=69292&edit=1 > > ID: 69292 > Updated by: c...@php.net > 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: > >> 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> > > > Previous Comments: > ------------------------------------------------------------------------ > [2015-03-25 14:34:19] bj...@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] c...@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 > > ------------------------------------------------------------------------ > [2015-03-24 20:33:53] scott at perturb dot org > > Description: > ------------ > I download the PHP release .tar.bz2 files from the php.net all the time to do > testing. 99% of the time I navigate to the download page on my local machine, > and copy and paste the URL in to a terminal on the server I want to compile > on. The download URLs look like this: > http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror which I then feed > to wget: > > $ wget http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror > > --2015-03-24 08:58:06-- > http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror > Resolving br1.php.net (br1.php.net)... 187.73.33.52 > ** [snipped] ** > HTTP request sent, awaiting response... 200 OK > Length: 11396771 (11M) [application/octet-stream] > Saving to: ‘mirror’ > > mirror 100%[========================>] 10.87M 1.22MB/s > in 11s > > 2015-03-24 08:58:17 (1006 KB/s) - ‘mirror’ saved [11396771/11396771] > > Note that the file that gets written to disk is "mirror" and not > php-5.3.29.tar.bz2. It's a minor annoyance, but it seems really easily fixed. > > Test script: > --------------- > N/A > > Expected result: > ---------------- > When I wget a URL from a server, it should have the right file name. > > Actual result: > -------------- > Wget uses the part of the URL after the last "/" as the output filename. > Arguably this is a bug in Wget, but it's also something we can easily work > around on the php-web side. > > Someone already thought of this, because there is mention of wget style > download links in the code: > > https://github.com/php/web-php/blob/master/error.php#L136 > > If we remap the filename in the download URL to be at the END, it should > solve this problem. > > > ------------------------------------------------------------------------ > > > > -- > 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 > -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
