develooper Front page | perl.libwww | Postings from November 2001

Re: [ libwww-perl-Bugs-477013 ] Deleted cookies persist across redirect

Thread Next
Gisle Aas
November 16, 2001 16:17
Re: [ libwww-perl-Bugs-477013 ] Deleted cookies persist across redirect
Message ID:
Steve Fink <> writes:

> In fact, I think I'll pester you directly for the next thing -- I was
> just wondering if you had any plans to change Net::HTTP (as you
> threaten in the documentation). If so, let me put in a feature request.

I think the interface is pretty good now and will basically stay that

> I've sort of inverted Raphael Manfredi's CGI::Test framework, because
> I wrote a similar application before I discovered his, and wanted to
> reuse big chunks of his code. But he had built it in such a way that
> it was impossible to reuse his objects without reusing his whole
> framework, which doesn't work for me because he emulates a web server
> and I need to run against a real one. So I kind of inverted the way he
> does things, mainly by creating a new LWP::Protocol handler for http
> that redirects CGI URLs through his framework. As part of that, I have
> a place where I'd really like to use the facilities of Net::HTTP
> without creating a real socket connection. But Net::HTTP subclasses
> IO::Socket::INET, so I can't fake it out with an IO::Scalar or
> something. The parts I want to reuse are things like
> read_response_headers and format_request; any plans to separate out
> the protocol format manipulation from the I/O, perhaps by delegating
> to an IO::Handle instead of subclassing?

I don't think I can do that directly as you suggest without slowing it
down considerably.  For speed reasons I want the methods of Net::HTTP
to be able to assume the object is a GLOB so we can access the
attributes directly.

I have actually been thinking of doing something similar to what you
suggest because I want to set up a test suite for it that does not
require talking to a server.  I would also like to be able to use
Net::HTTP on things that are not a socket.  It might for instance make
sense to talk HTTP on a pipe.

What I suggest is this:

  We move all the methods of Net::HTTP out into a package
  that does not inherit from anything.  We might call it
  Net::HTTP::Methods or something.  This class is supposed
  to be used as a mixin.

  Net::HTTP will then basically just be a simple class that
  combines IO::Socket::INET and Net::HTTP::Methods.

      package Net::HTTP;
      use base qw(Net::HTTP::Methods IO::Socket::INET);

  We should also replace 'print $self' in the methods
  with '$self->syswrite()' so you don't have to tie
  the object if it is not an IO::Handle.

  We would then probably also make a:

     package Net::HTTPS;
     use base qw(Net::HTTP::Methods IO::Socket::SSL);


In this way it should be easy to reuse this stuff anyway you like.

Does this sound like a plan?
Can anybody suggest a better name than 'Net::HTTP::Methods'?


> Right now, I'm trying to track down "uninitialized" warnings that
> appear to result from Net::HTTP's use of ${*$self}{'http_buf'} (I
> tried faking it out by taking an IO::Scalar and reblessing it into
> Net::HTTP, which appeared to work until I saw all the warnings. And
> yes, I know that's a horrible thing to do.)
> Thank you very much for libwww! It's amazing how much mileage I've
> gotten out of it.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About