to override it.
…es to override this. Used by the HTTPS support in LWP::Protocol::https11.pm.
Subject: [PATCH] Resolve "Short Write" To: firstname.lastname@example.org Date: Tue, 7 Aug 2001 13:34:24 -0400 (edt) The "short write" error reported by http.pm is a shorthand for "Your operating system has exploited a perfectly legal feature that apparently has not been encountered in other operating systems to date." That feature is the possibility that syswrite might return having only written part of the requested record, and I have encountered it under QNX4 for file sizes in excess of 10K bytes. This patch does the obvious loop to write out the rest. -Norton Allen
Subject: accept schemantics for HTTP::Daemon and IO::Socket differ To: email@example.com Date: Mon, 06 Aug 2001 15:02:32 -0700 Hello, In an array context IO::Socket::accept will return the socket and the peer returned from ::accept. HTTP::Daemon::accept always only returns the socket, not keeping the same schemantics that you would except by reading the HTTP::Daemon manual page. Here's a patch to fix this.
… M. Burke" <firstname.lastname@example.org>
Subject: fix for language-matching in HTTP::Negotiate To: gisle@ActiveState.com Date: Sun, 27 May 2001 18:41:49 -0600 This fixes some odd problems in HTTP::Negotiate's treatment of language tags: first, it failed to smash case in one place, and second, it assumed that if I accept language A, and you have language AB, then AB is fine. It now says that if I accept A, and you have A-B that that's fine. Would you believe I meant to make this fix /three/ years ago?
failed. Redirects should not really be like that.
Set-Cookie2 headers. In that case we used to ignore all Set-Cookie headers. Now we only ignore those Set-Cookie headers that reference the same cookie as a Set-Cookie2 header.
Subject: no LWP::Protocol and LWP::Protocol::nogo To: email@example.com Date: Sat, 05 May 2001 00:42:32 -0600 I was grinding my teeth the other day about that fact that if one created a CGI that said: #!/bin/sh echo Location: file:///etc/passwd echo and then directed a Perl-based HTTP proxy server to access that URL, it would merrily follow redirection to that local file. So I created a class, 'LWP::UserAgent::nogo', that one can name as the implementor for any protocols (like 'file') that one wishes to disable.
Subject: suggested changes to LWP::UserAgent 1.89 To: firstname.lastname@example.org Date: Sat, 05 May 2001 01:47:58 -0600 Attached are some suggested changes to LWP::UserAgent -- first the whole new UserAgent.pm file, and then the diffs between than and v1.89 -- whichever you find easiest to read. They changes several things: First, it updates the behavior of redirect_ok according to 2068 (previous things said "don't silently redirect POST"; 2068 says "silently redirect only HEAD and GET"); then it says not to follow redirect to file:... urls; then it allows setting, on a per-UA basis, what request types it'll allow redirection for, controlled via the 'redirect_requests' attribute. I add per-user attributes for controlling access to protocols; that involved changing simple_request to rely on LWP::Protocol::nogo, and also adding protocols_allowed and protocols_forbidden accessors. That also involved rewriting (and also moving, for sake of the flow of the documentation) the is_protocol_supported routine. And finally, the thousandth time I started a program with both "use LWP;" AND "use HTTP::Request::Common;", I swore I would somehow make it more concise for the 95% of requests that are either $ua->request(GET(...)) or $ua->request(POST(...)), and so I made shortcut methods: $ua->get(...) as a shortcut for require HTTP::Request::Common; $ua->request(HTTP::Request::Common::GET(...)); and ditto for head, post, and put. I ran the idea past some other programmer folk I know to test whether this was just some private mania of mine, but they all liked the idea. I think it also files down one of the pointier corners on the learning curve for these modules, and makes the code easier to read: to a neophyte, $response = $browser->get($url) is a whole lot clearer than the slightly odd-looking $response = $browser->request(GET($url)). ("Why do I need to get it, and then request it?", etc.)