Re: WWW::Mechanize and forcing POST
Andy Lester wrote: Could you told us what page Mech is having a different behavior than MSIE? We really want Mech having the same behavior as MSIE and if the behavior with that page is different that's a bug in Mech. It's not a bug in Mech. Mech IS a browser-in-an-object, but it's not meant to emulate any given browser. There are plenty of things that browsers handle that Mech doesn't, mostly in the badly-formed HTML department. Of course, you are right. I didn't explain correctly myself. I meant a bug in the chain of objects (in the system). I didn't know where the bug was, but I knew there was a bug. Juan
Re: normalize hostname case when looking up credentials
Andrew Pimlott wrote:
Is there any reason not to normalize the hostname used for looking up
credentials, as passed to UserAgent-credentials?
It would also be terribly useful to allow undef as a wildcard.
Actually, I seem to remember reading some discussion about how to
generalize -credentials. What's the current thinking?
I don't understand what are you trying to do.
What's MSIE/Mozilla doing in the same scenario?
Is it also normalizing the hostname?
Juan
--- ../LWP/UserAgent.pm 2003-12-31 10:58:09.0 -0800
+++ /home/andrew/UserAgent.pm 2004-03-31 09:38:49.0 -0800
@@ -542,7 +542,7 @@
sub credentials
{
my($self, $netloc, $realm, $uid, $pass) = @_;
-@{ $self-{'basic_authentication'}{$netloc}{$realm} } = ($uid, $pass);
+@{ $self-{'basic_authentication'}{lc $netloc}{$realm} } = ($uid, $pass);
}
@@ -551,7 +551,7 @@
my($self, $realm, $uri, $proxy) = @_;
return if $proxy;
-my $host_port = $uri-host_port;
+my $host_port = lc $uri-host_port;
if (exists $self-{'basic_authentication'}{$host_port}{$realm}) {
return @{ $self-{'basic_authentication'}{$host_port}{$realm} };
}
Re: cookie handling patch
Aleksandr Guidrevitch wrote: We've found that LWP incorrectly handles cookies containing ';' in the cookie value. The patch (test case and fix) is attached Could you point me to a web page that is already sending these kind of cookies? Does it work under MSIE/Mozilla? Juan
Re: cookie handling patch
Aleksandr Guidrevitch wrote: JUANMARCOSMOREN wrote: Aleksandr Guidrevitch wrote: We've found that LWP incorrectly handles cookies containing ';' in the cookie value. The patch (test case and fix) is attached Could you point me to a web page that is already sending these kind of cookies? Does it work under MSIE/Mozilla? Nope, it is our internal project, not available to outer world. Both we know that neither mozilla nor msie correctly handle such cookies :(( So, why do you want ';' in cookies if they are not handled correctly by the most used HTTP implementations (MSIE and Mozilla)? According RFC in **quoted** string you can put almost anything. See http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2109.html for definition of cookie: People don't care much about the HTTP RFC what people really want is to be compatible with MSIE and Mozilla. av-pairs= av-pair *(; av-pair) av-pair = attr [= value]; optional value attr= token value = word word= token | quoted-string See http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2068.html for definition of quoted-string: A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( *(qdtext) ) qdtext = any TEXT except The backslash character (\) may be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair= \ CHAR So, since the patch doesn't break original libwww behavior (according to the test suite) and provides more proper implementation of rfc, it looked to me as a good candidate for inclusion into libwww. I think this patch solves nothing and add useless code to the library. It is not a good idea to apply this patch. Juan
Re: URI support for OpenURL
Tim Brody wrote: I've written a module for parsing and constructing OpenURLs (http://library.caltech.edu/openurl/) within the URI framework: http://santos.ecs.soton.ac.uk/URI-openurl-0.1.tar.gz OpenURL is not a URI format per-se, but a means of transporting structured metadata via URIs (e.g. http://host/path?openurl_query). As the proposed NISO specs have an abstraction layer (entities) I have built support for these within URI by casting between different entity classes, all of which are subclasses of URI::openurl, which in turn is a subclass of _server. This allows the construction of OpenURLs through methods, rather than hierarchical hash-trees. My implementation of this may be bad (the only way I could think to get around URI's single-scalar storage), so would appreciate any comments! What does OpenURL pretend to solve? Could you give some examples of usage that can't be done without OpenURLs?
Re: LWP::Simple: patch to let you see last error
Ed Avis wrote: When LWP::Simple::get() fails it would often be useful to print a more informative error message than just 'get failed'. The following patch lets you say $got = get 'http://perl.org/'; die could not get page: $LWP::Simple::error if not defined $get; The error message is not perfect but it is a lot better than nothing. $LWP::Simple::error is set by all the functions not just get(). PLEASE, DON'T ADD GLOBAL VARIABLES!!! If LWP::Simple::get() is not a good interface then use the complicated one. Global variables are not thread safe!!! Global variables are bad programing!!! Juan
Re: LWP::Simple: patch to let you see last error
Ed Avis wrote: On 21 May 2004, Gisle Aas wrote: When LWP::Simple::get() fails it would often be useful to print a more informative error message than just 'get failed'. I've decided to not apply this patch. I want to keep the LWP::Simple as simple as it can be. I recommend using the full LWP::UserAgent interface if you need the extra error information. Also interfaces involving globals are not really pleasant. My feeling is that the truly simple interface would throw an exception with an informative message on error, and then you wouldn't have to manually check the return value for each call. But this suggestion wasn't well received on the list. If you want to throw an exception fine with me, but don't use global variables! I'm not sure the easiest way to work with exceptions in perl, but exceptions are not global, they are local to the function. You make a good point about global variables, however I felt it was overridden by the importance of usable error reporting. The global $! for error messages is rather ugly, but still any good beginner's Perl tutorial recommends to always put $! in every error message. DO NOT USE GLOBALS!!! If a tutorial tells you to use a global variable then that's a bad tutorial! At the moment I have an application which uses LWP::Simple but I'm having difficulty getting usable bug reports from users. The app can only print 'download failed' but once you know the reason it failed the problem is much easier to fix. At the moment I have to send out perl oneliners for the users to run to find out the problem, since there is no way to get LWP::Simple to return the error message. Then, as I said in my prior post, use the complicated interface of LWP. It looks like there is a niche for a library that makes it simple to download URLs, but also makes it simple to do the right thing, which in my opinion means always checking the success of each call and giving an informative error message. As I said there's a complicated interface you should be using anyway, instead the crappy LWP::Simple. Might you include such a library (with interface similar to LWP::Simple) in the LWP bundle, or should I distribute it separately? There's already a library.
