raw() Method

Aaron Bawcom (aaron@bawcom.net)
Fri, 08 Aug 1997 18:10:44 -0700 

Hello,
	As always, tremendous thanks to everyone
who has helped contribute to the libwww library.

This E-Mail is in regards to a suggestion.

I am currently using:

$Id: Daemon.pm,v 1.13 1996/11/13 13:22:21 aas Exp $

in an application for my company. I have currently
modified the "get_request" method within the
HTTP::Daemon::ClientConn class. I have changed the
behavior of the method such that every byte is read
in one at a time and appended onto $buf instead
of reading 1024 bytes at a time. I also added
a private variable to the class called $raw.
As soon as "get_request" determines the nature of
the request (either HTTP 1.X OR HTTP 0.9) it exits
the read loop and $buf is assigned to $raw.
Finally, I've added a method to the class called
raw() which simply returns the contents of the
private variable $raw.

Here is why.

A decision within the company was made where it
was decided that it was better to piggyback
our protocol requests on top of HTTP instead
of having two daemons on two different ports.
We need both the functionality of a web server
and the custom functionality that we code into
the program. The best way I see doing this
is for the HTTP::Daemon to take as much as
needed to complete an HTTP request and supply
what it found in "raw()" but don't close the
connection because other stuff may happen on
the connection. The second part is already
implemented. The caller closes the connection
when the object has no other references.
This seemed a much better solution than to
overide the entire method myself especially
when HTTP::Daemon creates the new ClientConn
internally.
Also, I think it is a good idea to read in
one byte at a time because HTTP is a logical
based protocol as opposed to a message based
protocol.

I looked through the subclasses and found
nothing that provided this functionality.
Hopefully I just missed exactly what I
was looking for and the class can stay the
same. Otherwise, the licensing for the
product will be a bit more tricky.
Thanks again.

-- Aaron Bawcom