Re: Bug #69292 [Opn]: Download links are not wget compatible

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, <cmb@php.net> wrote: > Edit report at https://bugs.php.net/bug.php?id=69292&edit=1 > > ID: 69292 > Updated by: cmb@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] <ç¥Ñ˜IçVp > ~Œôù¸hhttp://www.gnu.org/software/wget/manual/wget.html#Download-Options> > > > Previous Comments: > ------------------------------------------------------------------------ > [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 > > ------------------------------------------------------------------------ > [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 >