Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Tag: libwww-perl/5.…
Commits on Oct 15, 2003
  1. Release 5.72

    authored
  2. From: Ken Williams <ken@mathforum.org>

    authored
    Subject: Patch for LWP Makefile.PL
    To: libwww@perl.org
    Cc: gisle@ActiveState.com, macosx@perl.org
    Date: Fri, 11 Jul 2003 10:18:12 -0500
    
    Hi,
    
    There's still a flaw with the conflict-detection in LWP's Makefile.PL
    that prevents /usr/bin/head from being overwritten by HEAD on Mac OS
    X. The problem is that MakeMaker uses $Config{installscript} as the
    installation location for EXE_FILES items, not $Config{sitebin} as was
    assumed in the code.  Therefore the conflict never gets detected when
    those two paths are different.
    
    The patch below is against LWP 5.69.
  3. From: "Sean M. Burke" <sburke@cpan.org>

    authored
    Subject: Small HTTP::Cookies::Netscape docfix
    To: Gisle Aas <gisle@aas.no>
    Date: Fri, 20 Jun 2003 13:10:07 -0800
    
    Small HTTP::Cookies::Netscape docfix attached.  Nothing special.
  4. Change 61819 by jand@jand-tofino on 2003/03/25 19:16:10

    authored
            LWP: Just because the stash is defined doesn't mean the authentication
                 scheme is available now.  This could also be just the second
                 request trying to use this scheme (where the first attempt
                 created the stash but didn't define the authenticate() method).
                 See also: LWP::Authen::Ntlm
  5. s/\r//g

    authored
  6. LWP::UserAgent now implements a 'max_redirect' attribute with a

    authored
    default value of 7.  This should also fix the problem where
    redirects to the same URL to get a cookie set did not work.
    Based on a patch by Sean M. Burke C<sburke@cpan.org>.
  7. LWP::UserAgent now deals with 303 and 307 redirects. The behaviour

    authored
    of 302 redirects has also changed to be like 303; i.e. change the
    method to be "GET".  This is what most browsers do.  Based on
    a patch contributed by Tom Hughes <thh@cyberscience.com>.
  8. Pick up version number from CVS.

    authored
  9. Extend copyright.

    authored
  10. Mark internally generated responses with a Client-Warning header

    authored
    and also repeat the status line in the content body.  This make
    sure that 'lwp-request http://bogus.domain'; is not silent.
  11. From: "Brian J. Murrell" <93d103a48bddc5503b63e92b382f5012@interlinx.…

    authored
    …bc.ca>
    
    Subject: libwww: no Content-Length in POST with no content fix
    To: gisle@ActiveState.com
    Date: Thu, 15 Nov 2001 11:14:09 -0500
    Resent-From: "Brian J. Murrell" <93d103a48bddc5503b63e92b382f5012@interlinx.bc.ca>
    
    Hello Gisle,
    
    I ran across a small (bug?) annomly with libwww 5.60 and POSTing with
    no content.  It seems that only if there is content in the POST
    request that a Content-Length: header is generated.  Unfortunately,
    Squid barfs at this.  It seems to want to know the content length even
    if it is zero.
    
    Here is a patch that seems to fix the problem -- at least here in my
    application:
  12. From: Shlomo Yona <shlomo@cslx.haifa.ac.il>

    authored
    Subject: LWP::UserAgent
    To: gaas@cpan.org
    Date: Mon, 1 Apr 2002 14:59:03 +0300 (IDT)
    
    Hello.
    
    
    Just a comment about a possible typing-error in the LWP::UserAgent
    documentation:
    
    Where you explain about simple_request you say:
    "If differs from..."
    and I believe it should be:
    "It differs from..."
  13. Avoid undef warning.

    authored
  14. From: Joshua Chamas <joshua@chamas.com>

    authored
    Subject: PATCH: Peer certificate not verified for https Crypt::SSLeay
    To: libwww@perl.org
    Date: Mon, 18 Mar 2002 13:34:43 -0800
    Organization: NodeWorks <http://www.nodeworks.com>
    
    Hey,
    
    Here is a patch against libwww-perl-5.64 that turns off the
    "Client-SSL-Warning" => "Peer certificate not verified"
    when Crypt::SSLeay has been configured to do peer certificate
    verification.  By wrapping the call in an eval {}, this patch
    should also be compatible with other SSL implementations that
    do not support this sock->get_peer_verify API.
  15. Requests for some non-HTTP URLs would fail if the cookie_jar

    authored
    was enabled.  The HTTP::Cookies::add_cookie_header now ignored
    not-HTTP requests.
  16. Version 5.71

    authored
  17. Check mailto: URLs

    authored
Commits on Oct 14, 2003
  1. Doc typo

    authored
  2. From: Ilya Zakharevich <nospam-abuse@ilyaz.org>

    authored
    Subject: [PATCH] libwww 5.69
    To: libwww@perl.org
    Date: Tue, 14 Oct 2003 01:37:16 -0700
    
    This patch enables OS/2 build.
    
    Thanks,
    Ilya
  3. From: Matthew Eldridge <eldridge@Graphics.Stanford.EDU>

    authored
    Subject: Re: libwww-perl-5.70
    To: Gisle Aas <gisle@activestate.com>
    Cc: libwww@perl.org
    Date: Tue, 14 Oct 2003 10:43:35 -0700
    Gnus-Warning: This is a duplicate of message <16268.13767.203575.315022@radiance.Stanford.EDU>
    
    
    Gisle Aas writes:
     > I'm trying to go through my backlog of bug reports and patches
     > for LWP. Today I've been fixing HTML::Form issues, and I've
     > just uploaded libwww-perl-5.70 as snapshot of this
     > work-in-progress. I expect more releases to come out soon.
     >
     > The changes that made it to v5.70 where:
     >
     > File::Listing::apache by Slaven Rezic <slaven@rezic.de>
     >
     > HEAD requests now work properly for ftp: URLs. Patch by Ville
     > Skytt� <ville.skytta@iki.fi>.
    
    I was having trouble with failed HEAD requests that delegated down to
    Protocol/ftp.pm.  In my particular application I know that I have the
    first START bytes, I just don't know how long the rest of the file is,
    so I was calling HEAD so I could add a header to the request like
    this:
    
      $request->header( Range => "bytes=$START-$END" );
    
    However, after poking around a bit I found a much better solution to
    my problem.  As documented here,
    
      http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
    
    a valid range request need not include an ending byte number.  Thus I
    could just say
    
      $request->header( Range => "bytes=$START-" );
    
    and be done with it.
    
    However, the code that handles the Range header in LWP/Protocol/ftp.pm
    can't handle this case -- it insists that the starting and ending byte
    numbers both be defined.
    
    I've attached a patch that fixes this particular case.  The spec
    defines some more variations on how the range header can be used, but
    I don't know how many of them are workable or useful for ftp.
  4. Try harder to locate sendmail.

    authored
Something went wrong with that request. Please try again.