Date: Mon, 21 Jul 1997 23:04:31 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: Apache <new-httpd@apache.org>
Subject: Re: mod_isapi
In-Reply-To: <Pine.GSO.3.95.970721215010.14303A-100000@veal.organic.com>
Message-ID: <Pine.LNX.3.95dg3.970721225459.30497B-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Mon, 21 Jul 1997, Alexei Kosut wrote:

> Actually, it's a tad worse. You can send a "Content-length: 10000000" and
> Apache will malloc() ten megabytes. I do see that as a problem. But I
> forgot to do anything about it... Couldn't think of quite the right thing
> to do.

You mean it does this with your mod_isapi right?

> Makes sense. Only one problem. IIS doesn't do that. It doesn't set the
> variables to what CONTENT_LENGTH would be. It doesn't pass the data into
> the buffer unmodified. It tacks on a \0 and adds one to the
> numbers. Which means that if there is more than 48k, the algorithm
> described in the spec goes to hell, because everything's off by one. The
> only way I could figure out how to do this without dissasembling IIS to
> figure out what the hell it does was to send all the data to the client,
> tack on the null, and up both numbers (so they keep equal). It seems to
> work with the demos that come with IIS.

Ok I don't see why you can't also use a 48k buffer and do the same
thing... rather than just reading it all at once and allocating a lot of
memory.  Was it just a first-pass convenience thing you plan to clean up? 
I'll buy that.  Or maybe I'm confused.

> aren't in use anymore, and so I couldn't figure out how to make it unload
> the DLL at a good time.

Couldn't you just register a cleanup for it in the appropriate pool?
Probably the connection pool given the sounds of the api.

> It's not that trivial. Unless they have knowledge of Apache's
> internals. But a CGI script can do the same thing, unless you're using
> suexec. Remember, DLLs have seperate address spaces unless they're
> explicitly merged by linking to an export library, or calling
> GetProcAddress(). So the DLL can only talk to Apache through the
> interfaces Apache sets up for it. Similar to a CGI, in that respect.

The interfaces pass it pointers to Apache's memory space right?  DLLs have
access to the calling process' memory space.  DLLs are just mapped above a
certain address, much like shared libraries are mapped in unix.  Given
acess to Apache's memory space you can do anything to it.  It's trivial to
have knowledge of Apache's internals, you just get the source code and
build it the same way we do and you'll have a symbol map.

Dean