Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPAN misinterprets 404 status as 407 #13533

Closed
p5pRT opened this issue Jan 17, 2014 · 10 comments
Closed

CPAN misinterprets 404 status as 407 #13533

p5pRT opened this issue Jan 17, 2014 · 10 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 17, 2014

Migrated from rt.perl.org#121023 (status was 'rejected')

Searchable as RT121023$

@p5pRT
Copy link
Author

p5pRT commented Jan 17, 2014

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

When CPAN tries to fetch a module using LWP and if it is
fetching through a proxy, a 404 from the proxy confuses
LWP into thinking the proxy isn't working -- when the
proxy really can't find the listed URL.

I've seen this before in other cases, but due to a recent
upgrading from cyg32->cyg64, my cpan-config file had some
bogus values -- which made this error easier to reproduce).

The output generated when it couldn't find things was​:

law.Bliss> cpan
cpan[1]> look Test​::Reporter​::Transport​::Metabase
CPAN​::SQLite not installed, trying to work without
CPAN​: Storable loaded ok (v2.27)
Reading '/var/cache/CPAN/Metadata'
  Database was generated on Sun, 12 Jan 2014 12​:41​:02 GMT
Reading '/Share/CPAN/sources/authors/01mailrc.txt.gz'
CPAN​: Compress​::Zlib loaded ok (v2.033)
............................................................................DONE
CPAN​: LWP​::UserAgent loaded ok (v6.05)
Fetching with LWP​:
http​://mirrors.kernel.org/CPAN http​://www.perl.com/CPAN/modules/02packages.details.txt.gz
LWP failed with code[404] message[Not Found]

Proxy authentication needed!
(Note​: to permanently configure username and password run
  o conf proxy_user your_username
  o conf proxy_pass your_password
  )
Username​:
CPAN​: Term​::ReadKey loaded ok (v2.30)
Password​:

(To reproduce, a bogus value in "urllist" like​:

  'urllist' => [q[http​://mirrors.kernel.org/CPAN http​://www.perl.com/CPAN/],q[http​://www.perl.com/CPAN/]],

can be used...)

CPAN shouldn't equate '404' not found, with '407' (proxy_auth_required).

(side note -- not the point of this bug, but would have circumvented
it​: CPAN might recognize that the URL addr is suspect (raw space in URL
is unlikely in a standard URL as well as unlikely in a CPAN mirror addr)).

In any event, unless it gets back a '407', it likely shouldn't be
asking for a User/PW, but just go on to next mirror or next method of
fetching...(which for a missing module, may work, but for a bogusly
formatted urllist, likely won't). Have seen this recently on linux
where I had uploaded to cpan, a new version of a module -- but
it hadn't been mirrored on mirrors yet -- that "not found" 404 gave
the same symptoms of asking for username/pw, but hitting return
to get past that, it was fetchable from cpan.org...

Perl Info

Flags:
    category=library
    severity=medium
    module=CPAN

This perlbug was built using Perl 5.16.2 - Sat Jan 26 21:59:13 UTC 2013
It is being executed now by  Perl 5.16.2 - Sat Jan 26 21:52:41 UTC 2013.

Site configuration information for perl 5.16.2:

Configured by abuild at Sat Jan 26 21:52:41 UTC 2013.

Summary of my perl5 (revision 5 version 16 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi
    uname='linux build35 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux '
    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
    libpth=/lib64 /usr/lib64 /usr/local/lib64
    libs=-lm -ldl -lcrypt -lpthread
    perllibs=-lm -ldl -lcrypt -lpthread
    libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.17'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'

Locally applied patches:
    


@INC for perl 5.16.2:
    /home/law/bin/lib
    /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.16.2
    /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/5.16.2
    /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/site_perl
    .


Environment for perl 5.16.2:
    HOME=/home/law
    LANG=en_US.utf8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_CTYPE=en_US.utf8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/law/bin/lib:/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:.:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib
    PERL5OPT=-Mutf8 -CSA -I/home/law/bin/lib
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Jan 17, 2014

From @Leont

On Fri, Jan 17, 2014 at 8​:09 PM, Linda Walsh <perlbug-followup@​perl.org>wrote​:

[Please describe your issue here]
When CPAN tries to fetch a module using LWP and if it is
fetching through a proxy, a 404 from the proxy confuses
LWP into thinking the proxy isn't working -- when the
proxy really can't find the listed URL.

I've seen this before in other cases, but due to a recent
upgrading from cyg32->cyg64, my cpan-config file had some
bogus values -- which made this error easier to reproduce).

The output generated when it couldn't find things was​:

law.Bliss> cpan
cpan[1]> look Test​::Reporter​::Transport​::Metabase
CPAN​::SQLite not installed, trying to work without
CPAN​: Storable loaded ok (v2.27)
Reading '/var/cache/CPAN/Metadata'
Database was generated on Sun, 12 Jan 2014 12​:41​:02 GMT
Reading '/Share/CPAN/sources/authors/01mailrc.txt.gz'
CPAN​: Compress​::Zlib loaded ok (v2.033)

............................................................................DONE
CPAN​: LWP​::UserAgent loaded ok (v6.05)
Fetching with LWP​:
http​://mirrors.kernel.org/CPAN
http​://www.perl.com/CPAN/modules/02packages.details.txt.gz
LWP failed with code[404] message[Not Found]

Proxy authentication needed!
(Note​: to permanently configure username and password run
o conf proxy_user your_username
o conf proxy_pass your_password
)
Username​:
CPAN​: Term​::ReadKey loaded ok (v2.30)
Password​:

(To reproduce, a bogus value in "urllist" like​:

'urllist' => [q[http​://mirrors.kernel.org/CPAN http​://www.perl.com/CPAN/
],q[http​://www.perl.com/CPAN/]],

can be used...)

CPAN shouldn't equate '404' not found, with '407' (proxy_auth_required).

(side note -- not the point of this bug, but would have circumvented
it​: CPAN might recognize that the URL addr is suspect (raw space in URL
is unlikely in a standard URL as well as unlikely in a CPAN mirror addr)).

In any event, unless it gets back a '407', it likely shouldn't be
asking for a User/PW, but just go on to next mirror or next method of
fetching...(which for a missing module, may work, but for a bogusly
formatted urllist, likely won't). Have seen this recently on linux
where I had uploaded to cpan, a new version of a module -- but
it hadn't been mirrored on mirrors yet -- that "not found" 404 gave
the same symptoms of asking for username/pw, but hitting return
to get past that, it was fetchable from cpan.org...

CPAN.pm is maintained on CPAN, outside of core, you can look this up by
doing «corelist -u CPAN». You may want to file this ticket at
https://rt.cpan.org/Dist/Display.html?Queue=CPAN, metacpan.org or
search.cpan.org would have told you that.

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 17, 2014

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jan 17, 2014

From perl-diddler@tlinx.org

On Fri Jan 17 11​:59​:32 2014, LeonT wrote​:

CPAN.pm is maintained on CPAN, outside of core, you can look this up
by
doing «corelist -u CPAN». You may want to file this ticket at
https://rt.cpan.org/Dist/Display.html?Queue=CPAN, metacpan.org or
search.cpan.org would have told you that.


When I do a "corelist -u CPAN", I get​:

corelist -u CPAN

Data for 2013-12-20
CPAN was first released with perl 5.004
upstream​: cpan
bug tracker​: unknown


If it was released with perl, then how is it not part of the Core Perl distribution?

Is this because it is dual-"life"d?

@p5pRT
Copy link
Author

p5pRT commented Jan 17, 2014

From perl-diddler@tlinx.org

BTW -- is perlbug part of the CORE distribution?

If it was misdirected, it's a bug in perlbug -- as perlbug claimed it was part of 'core'.

perlbug asked what part it was in​: 'library',

what module​: CPAN

then took the bug report.

@p5pRT
Copy link
Author

p5pRT commented Jan 17, 2014

From @Leont

On Fri, Jan 17, 2014 at 10​:43 PM, Linda Walsh via RT <
perlbug-followup@​perl.org> wrote​:

When I do a "corelist -u CPAN", I get​:

corelist -u CPAN

Data for 2013-12-20
CPAN was first released with perl 5.004
upstream​: cpan
bug tracker​: unknown

----
If it was released with perl, then how is it not part of the Core Perl
distribution?

Is this because it is dual-"life"d?

Dual-lifed means it's distributed both in core and on CPAN. Dual-lifed
module should have one end that's upstream of the other. The appropriate
bugtracker is with the one associated with upstream, but in this case
perlbug doesn't know (bug tracker​: unknown), so it can't redirect you. That
should be fixed probably.

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 18, 2014

From @xdg

On Fri, Jan 17, 2014 at 6​:18 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

Dual-lifed means it's distributed both in core and on CPAN. Dual-lifed
module should have one end that's upstream of the other. The appropriate
bugtracker is with the one associated with upstream, but in this case
perlbug doesn't know (bug tracker​: unknown), so it can't redirect you. That
should be fixed probably.

And in this case, it would help to figure out if the error is in CPAN.pm or LWP.

David

--
David Golden <xdg@​xdg.me>
Take back your inbox! → http​://www.bunchmail.com/
Twitter/IRC​: @​xdg

@p5pRT
Copy link
Author

p5pRT commented Jan 18, 2014

From perl-diddler@tlinx.org

On Sat Jan 18 04​:42​:42 2014, xdg@​xdg.me wrote​:

And in this case, it would help to figure out if the error is in
CPAN.pm or LWP.
David


Would LWP prompt for user+passwd and say that to store them, permanently, use o conf proxy_user your_username + o conf proxy_pass your_password ??

I'd say that minimally, that implies CPAN. The HTTP error code is being reported correctly as 404 (since it is not found -- the proxy doesn't need user+pw).

@p5pRT
Copy link
Author

p5pRT commented Dec 15, 2017

From zefram@fysh.org

As already noted, this bug report is in the wrong queue. It should
be closed.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 15, 2017

@iabyn - Status changed from 'open' to 'rejected'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant