You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1997/12/12 09:30:11 UTC
1.3b3 stability
Given the almost complete lack of bug reports against 1.3 in general on
unix and 1.3b3 in particular I think that either:
- nobody is testing it
or,
- it's actually stable and we could have a unix release candidate
I tend to believe the latter :)
Dean
Re: 1.3b3 stability
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Laurie wrote:
>
> If we do release Unix before Windows, will we release Windows as 1.3.x
> or 1.4?
I thought we decided long ago to keep them in synch?
> What is left on the plate for Windows (I don't think ASP should hold it
> up, BTW)?
If the CGI issues are all cleared up (I think they are), then here are
the only outstanding Win32 issues I can pull off the top of my head:
o Installation (typical, full, whatever; README display, ...)
o Isn't there a mod_status issue in the bugdb?
o The tray app
o Source inclusion/availability
o Final check to convert any '//' comments into '/**/' in the
ifdef'd Win32 code (there may not be any)
I think there are a couple of others, but they're in the bugdb.
I wouldn't mind releasing a 1.3b4 for UNIX only, but the final
release needs to be synched for UNIX and Windoze (i.e., 1.3.0
on both released at the same time).
#ken P-)}
Re: 1.3b3 stability
Posted by Shane Caraveo <sh...@caraveo.com>.
> > And I'm not convinced ISAPI works at all. I haven't tried it since summer,
> > and I just recently tried to get an extension working, and couldn't. So
> > maybe it's broken. Anyone have any recent experience with mod_isapi?
>
> I don't have any mod_isapi modules - if I had I might try to debug it...
>
I've got the php isapi module parsing right now, but its not thread
safe yet. Have only tried it with mspws, not with apache, and am not
planning on doing any major work on it until we finish thread safety.
Shane
Re: 1.3b3 stability
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Fri, 12 Dec 1997, Ben Laurie wrote:
>
> > What is left on the plate for Windows (I don't think ASP should hold it
> > up, BTW)?
>
> Well, there's ISAPI. As a recent bug report, and the known bugs page for
> 1.3a1 points out, it doesn't work at all (crashes the server) if Apache is
> compiled for release. The debug version doesn't do this. I presume it's
> some optimization VC++ is doing, but could never figure out what it was
> (debuggers don't work very well on optimized w/o debugging symbols).
You can optimise and include debugging symbols, unlike some braindead
compilers.
>
> And I'm not convinced ISAPI works at all. I haven't tried it since summer,
> and I just recently tried to get an extension working, and couldn't. So
> maybe it's broken. Anyone have any recent experience with mod_isapi?
I don't have any mod_isapi modules - if I had I might try to debug it...
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: 1.3b3 stability
Posted by Paul Sutton <pa...@eu.c2.net>.
On Sun, 14 Dec 1997, Alexei Kosut wrote:
> On Sun, 14 Dec 1997, Paul Sutton wrote:
> Would you mind putting that ISAPI somewhere I could grab? I really
> don't feel like downloading and instaling IIS on my NT box to get the
> ISAPI stuff.
Yep, no problem. I'll mail it separately.
> As for documentation, what did you have in mind besides what's at
> http://www.apache.org/docs/mod/mod_isapi.html?
There are a few commands that aren't supported in mod_isapi, like
HSE_REQ_GET_SSPI_INFO and HSE_APPEND_LOG_PARAMETER. It would be nice if
these were listed.
//pcs
Re: 1.3b3 stability
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Sun, 14 Dec 1997, Paul Sutton wrote:
> Yep, ISAPI certainly works in a debug build. I haven't tried. My test
> ISAPI is the simplest example from the ISAPI SDK (it outputs "this is an
> ISAPI" or something). BTW I think we should document what version of ISAPI
> we implement, and list the functions we don't support.
Would you mind putting that ISAPI somewhere I could grab? I really
don't feel like downloading and instaling IIS on my NT box to get the
ISAPI stuff.
As for documentation, what did you have in mind besides what's at
http://www.apache.org/docs/mod/mod_isapi.html?
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: 1.3b3 stability
Posted by Paul Sutton <pa...@eu.c2.net>.
On Fri, 12 Dec 1997, Alexei Kosut wrote:
> On Fri, 12 Dec 1997, Ben Laurie wrote:
> > What is left on the plate for Windows (I don't think ASP should hold it
> > up, BTW)?
>
> Well, there's ISAPI. As a recent bug report, and the known bugs page for
> 1.3a1 points out, it doesn't work at all (crashes the server) if Apache is
> compiled for release. The debug version doesn't do this. I presume it's
> some optimization VC++ is doing, but could never figure out what it was
> (debuggers don't work very well on optimized w/o debugging symbols).
>
> And I'm not convinced ISAPI works at all. I haven't tried it since summer,
> and I just recently tried to get an extension working, and couldn't. So
> maybe it's broken. Anyone have any recent experience with mod_isapi?
Yep, ISAPI certainly works in a debug build. I haven't tried. My test
ISAPI is the simplest example from the ISAPI SDK (it outputs "this is an
ISAPI" or something). BTW I think we should document what version of ISAPI
we implement, and list the functions we don't support.
Paul
Re: 1.3b3 stability
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Fri, 12 Dec 1997, Ben Laurie wrote:
> What is left on the plate for Windows (I don't think ASP should hold it
> up, BTW)?
Well, there's ISAPI. As a recent bug report, and the known bugs page for
1.3a1 points out, it doesn't work at all (crashes the server) if Apache is
compiled for release. The debug version doesn't do this. I presume it's
some optimization VC++ is doing, but could never figure out what it was
(debuggers don't work very well on optimized w/o debugging symbols).
And I'm not convinced ISAPI works at all. I haven't tried it since summer,
and I just recently tried to get an extension working, and couldn't. So
maybe it's broken. Anyone have any recent experience with mod_isapi?
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: 1.3b3 stability
Posted by Ben Hyde <bh...@gensym.com>.
> What is left on the plate for Windows ... ?
- Install
- Replacement for signal handling
- Shaking out the Service interface
- Doc
- Stress testing
- Performance?
- handful of pending PATCH to shakeout
oh and "[PATCH] a bundle of multithreading changes"
Date: Mon, 1 Dec 1997 11:39:10 +0000 (GMT)
From: Paul Sutton <pa...@eu.c2.net>
Message-ID: <Pi...@ecstasy.localnet>
is, I suspect, the first in a series.
- ben h.
Re: 1.3b3 stability
Posted by Shane Caraveo <sh...@caraveo.com>.
> Dean Gaudet wrote:
> >
> > Given the almost complete lack of bug reports against 1.3 in general on
> > unix and 1.3b3 in particular I think that either:
> >
> > - nobody is testing it
> >
> > or,
> >
> > - it's actually stable and we could have a unix release candidate
>
> Could be! Though we'll have to do a 1.3b4, surely?
>
> If we do release Unix before Windows, will we release Windows as 1.3.x
> or 1.4?
>
> What is left on the plate for Windows (I don't think ASP should hold it
> up, BTW)?
I dont think asp should hold it up either, but I'll be happy when
that is done. I can then trash my M$ server I use for development
;).
One other issue I remember reading about some time ago was the thread
local storage, that the way it was done prevented exporting variables
to the api. I ran into the same problem with php3, we moved to the
tls api. Did this issue get resolved for apache?
Also, a problem I ran into, which may be related to the above, is
that I couldn't use popenf() and pclosef() in a loadable module.
Soon as I trashed those, and used plain ol open() and close(), it
worked. Never got a response on that one.
I havent been using apache heavily, but I havent ran into any
problems with it for what I have done.
Shane
Re: 1.3b3 stability
Posted by Paul Sutton <pa...@eu.c2.net>.
On Fri, 12 Dec 1997, Ben Laurie wrote:
> Dean Gaudet wrote:
> >
> > Given the almost complete lack of bug reports against 1.3 in general on
> > unix and 1.3b3 in particular I think that either:
> >
> > - nobody is testing it
> > or,
> > - it's actually stable and we could have a unix release candidate
Yeah!
> If we do release Unix before Windows, will we release Windows as 1.3.x
> or 1.4?
Um, tricky.
> What is left on the plate for Windows (I don't think ASP should hold it
> up, BTW)?
Let's see... installer fixups, making to work as a service when not in
\apache, adding registry key(s), fixing up the process/thread model,
documenting API restrictions when coding for multi-threading, not ignoring
LoadModule at restart, finding some way of rotating logs other than
stop/move file/start, for starters.
//pcs
Re: 1.3b3 stability
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 12 Dec 1997, Ben Laurie wrote:
> Could be! Though we'll have to do a 1.3b4, surely?
Oh yeah, I just wanted to wake everyone up :)
Dean
Re: 1.3b3 stability
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> Given the almost complete lack of bug reports against 1.3 in general on
> unix and 1.3b3 in particular I think that either:
>
> - nobody is testing it
>
> or,
>
> - it's actually stable and we could have a unix release candidate
Could be! Though we'll have to do a 1.3b4, surely?
If we do release Unix before Windows, will we release Windows as 1.3.x
or 1.4?
What is left on the plate for Windows (I don't think ASP should hold it
up, BTW)?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
RE: 1.3b3 stability
Posted by Lars Eilebrecht <La...@unix-ag.org>.
According to Dean Gaudet:
> Does this happen with 1.2.x? If so then I'm not gonna dig into it...
> 'cause I don't really want to think about the proxy. But if it's new to
> 1.3 then it's probably my fault with the vhost code... and then I will dig
> into it.
No it's not new to 1.3, I can reproduce it with 1.2.4, BUT... I'm
no longer able to reproduce the problem with a wrong REMOTE_HOST value
(example request #4 from my list, see my previous mail for details),
neither with 1.2.4 nor with 1.3b4-dev.
Intrinsically I only tested all the stuff to verify the REMOTE_HOST
problem... someone (using 1.3b2) posted a message about having problems
with wrong REMOTE_HOST values when using virtual hosts to a german
newsgroup some time ago. Either this was magically fixed or I did the
same stupid thing as the person who posted the original message. *shrug*
Nevertheless I still think the behaviour of Apache is debatable when
looking at the second and third fulluri-request from my previous mail.
ciao...
--
Lars Eilebrecht - Avoid hangovers, stay drunk!
sfx@unix-ag.org
http://www.si.unix-ag.org/~sfx/
RE: 1.3b3 stability
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 12 Dec 1997, Lars Eilebrecht wrote:
> some days ago someone posted a message about having problems with wrong
> REMOTE_HOST values... I just tested it and it appears that it is related to
> the fullURI handling.
Does this happen with 1.2.x? If so then I'm not gonna dig into it...
'cause I don't really want to think about the proxy. But if it's new to
1.3 then it's probably my fault with the vhost code... and then I will dig
into it.
Dean
RE: 1.3b3 stability
Posted by Lars Eilebrecht <La...@unix-ag.org>.
According to Dean Gaudet:
> Given the almost complete lack of bug reports against 1.3 in general on
> unix and 1.3b3 in particular I think that either:
>
> - nobody is testing it
>
> or,
>
> - it's actually stable and we could have a unix release candidate
>
> I tend to believe the latter :)
Me too, but I'm still wondering if someone can confirm the problems I
posted about fullURI problems? I wasn't able to track down the
bug (if there is one) myself.
Here's the message I already posted two times to the list...
-snip-
some days ago someone posted a message about having problems with wrong
REMOTE_HOST values... I just tested it and it appears that it is related to
the fullURI handling.
Example setup:
main server is 'server' and we have one IP-based virtual host ('proxy')
used as a proxy. ProxyRequests is turned off for the main_server
and enabled for the virtual host.
Let's look at the following requests sent from the 'client' to the
'TARGET' host/interface:
TARGET GET REMOTE_HOST REQUEST_URI
------------------------------------------------------------------------------
proxy http://proxy/cgi-bin/printenv client http://proxy/cgi-bin/printenv
proxy http://server/cgi-bin/printenv server /cgi-bin/printenv
server http://proxy/cgi-bin/printenv client http://proxy/cgi-bin/printenv
server http://server/cgi-bin/printenv server /cgi-bin/printenv
The first entry/result is correct, but all others are not...
The second entry has a wrong REMOTE_HOST. I expected to see 'proxy' instead
of 'server' as REMOTE_HOST.
The third request is processed although 'ProxyRequests Off' was set for
main_server. IMHO the request should be denied, because we haven't connected
to the 'proxy' address.
And the last entry is wrong too, because REMOTE_HOST should contain 'client'
instead of 'server'.
When I look at the access.log I see that only the second requests is
processed as a real proxy request, that is I see an access from 'client'
with the full URI and a second request from 'server' with the URI-path
(as noted above it shouldn't be 'server', but 'proxy').
For all other requests I see only one access in the logfile with 'client'
as the remote host. Note that I see 'client' in the access.log for the last
request, but REMOTE_HOST is set to 'server'. (!)
I especially see a security problem with the third example-request, because it
was handled internally although ProxyRequests was turned off for the
main_server.
Can anyone confirm this?
BTW, I tested with 1.3b3-dev.
-snap-
ciao...
--
Lars Eilebrecht - Apples have been a problem ever since eden.
sfx@unix-ag.org
http://www.si.unix-ag.org/~sfx/