Interesting dechunk question for cgi/isapi

[William A. Rowe, Jr.]

I'm running across one particularly troubling example in the MS ISAPI example
extensions [other than all of the bugs I've documented at 
www.apache.org/~wrowe/]

There is a chunking example that sends a chunked response to the client.  I 
imagine
other authors have written similar cgi scripts that attempt to do this as well.

Suppose we look for the cgi/isapi to set the chunked response flag, and then
insert our dechunk filter at the head of the output stack?  Think that 
would fly?
Of course we would simply rechunk later, but that's based on the server core.

Bill

Re: Apache History Project - Call for comments

[Thomas Eibner]

On Tue, May 14, 2002 at 08:30:49PM -0700, Doug MacEachern wrote:
> On Tue, 14 May 2002, Doug MacEachern wrote:
> 
> > On Wed, 15 May 2002, Thomas Eibner wrote:
> >  
> > > Full list of posters with more than 10 posts can be found at:
> > > http://stderr.net/history/topposters
> > 
> > cool, now i am tied with ben hyde.
> 
> haha, now i am 1 ahead of ben hyde, i'm #32 woohoo!

You're already way ahead, the archive we generated it from only goes
up to May 1st ;)

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

RE: Apache History Project - Call for comments

[Ryan Bloom]

I still have to post 600 more times to catch up to Dean.  I'll make it
some day.  Of course, his posts are usually more informative than mine.
:-)

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

> -Original Message-
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 14, 2002 8:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Apache History Project - Call for comments
> 
> On Wed, 15 May 2002, Thomas Eibner wrote:
> 
> > Full list of posters with more than 10 posts can be found at:
> > http://stderr.net/history/topposters
> 
> cool, now i am tied with ben hyde.
> 

Re: Apache History Project - Call for comments

[Doug MacEachern]

On Tue, 14 May 2002, Doug MacEachern wrote:

> On Wed, 15 May 2002, Thomas Eibner wrote:
>  
> > Full list of posters with more than 10 posts can be found at:
> > http://stderr.net/history/topposters
> 
> cool, now i am tied with ben hyde.

haha, now i am 1 ahead of ben hyde, i'm #32 woohoo!

Re: Apache History Project - Call for comments

[Doug MacEachern]

On Wed, 15 May 2002, Thomas Eibner wrote:
 
> Full list of posters with more than 10 posts can be found at:
> http://stderr.net/history/topposters

cool, now i am tied with ben hyde.

Re: Apache History Project - Call for comments

[Thomas Eibner]

On Sat, May 11, 2002 at 07:24:22PM +0100, Tony Finch wrote:
> On Sat, May 11, 2002 at 09:23:58AM -0700, Aaron Bannert wrote:
> > On Sat, May 11, 2002 at 12:16:48PM -0400, Jim Jagielski wrote:
> > > 
> > > +1. I think it's a great idea... I'd like to propose it as an
> > > ASF (sub)project.
> > 
> > +1 from me too.
> 
> +1

So how do we get anything rolling? Rich and I have cooked up what we see
as an initial roadmap for the project:

General History of Apache
  * Before Apache
  * Why Apache
  * Initial Development Team
  * How Apache became one of the most successful OSS projects to date

Apache httpd Release timeline 
  * Release Date
  * Changelog / Release notes
  * Tarball
  * Usage statistics
  * Other Important Release informaton
  Version
  Release Manager
  Security Fixes
  New Directives
  Changed Directives
  State (Alpha/Beta/GA)
  Etc.

Apache Software Foundation History
  * Project Profiles
  * Member Profiles
  Join Date
  First List Post
  Description of work done for project

Subprojects History
  * Convince at least one person from each project to participate and
maintain history of that project.
  * Short historical description
  * Usage statistics
  * Same project parts as the httpd history projects

Quote collection from development lists
  * Historical comments
  * Funny comments

We've already started on the httpd release timeline and we have
information exchanges over IRC that would fit better in a cvs repository,
so we'd really like to get something moving very soon now.

We've put our uptodate writings on http://stderr.net/history/ for now
and anyone is free to look and give suggestions.

One volunteer has already come forward to help us gather data and we've
compiled some statistics from this mailinglist showing how many posts
each person has made since '95:

Total Posts on [EMAIL PROTECTED]: 87510

  1: Dean Gaudet 5184  5.924%
  2: Ryan B. Bloom   4521  5.166%
  3: Jim Jagielski   4404  5.033%
  4: Rob Hartill 4200  4.799%
  5: Marc Slemko 3807  4.350%
  6: Ben Laurie  3769  4.307%
  7: Ken Coar3457  3.950%
  8: Brian Behlendorf3263  3.729%
  9: Randy Terbush   2996  3.424%
 10: William Rowe2859  3.267%
 11: Greg Stein  2315  2.645%
 12: Roy T Fielding  2099  2.399%
 13: Jeff Trawick1894  2.164%
 14: Ralf S Engelschall  1748  1.997%
 15: Bill Stoddard   1703  1.946%
 16: Robert S Thau   1699  1.941%
 17: Alexei Kosut1684  1.924%
 18: Chuck Murcko1503  1.718%
 19: Rasmus Lerdorf  1260  1.440%
 20: Martin Kraemer  1202  1.374%
 21: Sameer Parekh   1196  1.367%
 22: Dirk-Willem van Gulik   1064  1.216%
 23: Cliff Woolley   1011  1.155%
 24: Manoj Kasichainula   964  1.102%
 25: Justin Erenkrantz953  1.089%

Full list of posters with more than 10 posts can be found at:
http://stderr.net/history/topposters

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Apache and SOCKS

[GUMMALAM,MOHAN (HP-Cupertino,ex2)]

In Apache1.3 I remember seeing support for SOCKS in mod_proxy.  I do not see
any such support in Apache2.0.  I have looked through the email archives,
and have not come across any email thread yet which contains a discussion on
it.  So, was it a conscious decision to not have Socks support in Apache2.0?
If so, what were the reasons behind it?
Thanks,
Mohan.

Re: how to log apr_status_t diagnostics in mod_ssl...

[Greg Stein]

On Tue, May 14, 2002 at 09:29:47AM -0700, Justin Erenkrantz wrote:
> On Tue, May 14, 2002 at 08:13:00AM -0700, Ryan Bloom wrote:
> > module's logic tends to lag behind.  If you wanted to change all ssl_log
> > calls to ap_log_[r]error, I would be +1 for that too.
> 
> +1 to that.  I'd rather see us dump ssl_log() in favor of using our
> standard logging code - ap_log_[r]error.  I think it made sense to
> have it log to a separate file when it wasn't part of the core, but
> now that we distribute it, I believe it should follow our standard
> logging conventions.
> 
> My $.02.  -- justin

I'll call your $.02 and raise you another $.02

+1, ditto on all the above.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: PR 8482: server push CGIs broken

[Greg Ames]

Jeff Trawick wrote:
> 
> The PR was written for nph CGIs but it appears that any server push
> CGI is broken.
> 
> Apparently, core_output_filter() would need to switch between
> non-blocking and blocking bucket reads (and flush the output
> in-between) to get this to work.
> 
> For non-nph server push CGIs to work, other filters which buffer data
> may need something similar...

ouch...  If this works in 1.3, we probably should fix it.

Is this even limited to CGIs?  I would hope such a CGI could be ported to the
Apache module API without loosing functionality.

I vaguely recall a discussion about supporting a module/CGI which sends an
initial message to the client before doing a slow database query, perhaps when
filters were being designed.  Obviously such a thing won't work as desired now.

Greg

Re: how to log apr_status_t diagnostics in mod_ssl...

[Justin Erenkrantz]

On Tue, May 14, 2002 at 08:13:00AM -0700, Ryan Bloom wrote:
> module's logic tends to lag behind.  If you wanted to change all ssl_log
> calls to ap_log_[r]error, I would be +1 for that too.

+1 to that.  I'd rather see us dump ssl_log() in favor of using our
standard logging code - ap_log_[r]error.  I think it made sense to
have it log to a separate file when it wasn't part of the core, but
now that we distribute it, I believe it should follow our standard
logging conventions.

My $.02.  -- justin

RE: how to log apr_status_t diagnostics in mod_ssl...

[Ryan Bloom]

> From: [EMAIL PROTECTED] [mailto:trawick@rdu88-251-
> 253.nc.rr.com] On Behalf Of Jeff Trawick
> 
> mod_ssl uses ssl_log(), which doesn't allow the caller to pass in
> apr_status_t.  Should we add a new parameter for that, or should we
> add a separate function like ssl_log_error() with such a parameter?
> 
> I'd vote for adding a new parm to ssl_log() right after the 2nd
> parameter (and yes, I'll make the changes to the many callers :) ).
> 
> Also, the existing accesses to errno in ssl_log() should be yanked, or
> perhaps replaced with appropriate logic to handle whether or not an
> apr_status_t was passed in.
> 
> Comments?

Fix the ssl_log API so that it accepts the apr_status_t.  This is one of
the problems with having modules that use their own logs to store error
information.  When the core API changes to log more information, the
module's logic tends to lag behind.  If you wanted to change all ssl_log
calls to ap_log_[r]error, I would be +1 for that too.

Ryan

how to log apr_status_t diagnostics in mod_ssl...

[Jeff Trawick]

mod_ssl uses ssl_log(), which doesn't allow the caller to pass in
apr_status_t.  Should we add a new parameter for that, or should we
add a separate function like ssl_log_error() with such a parameter?

I'd vote for adding a new parm to ssl_log() right after the 2nd
parameter (and yes, I'll make the changes to the many callers :) ).

Also, the existing accesses to errno in ssl_log() should be yanked, or
perhaps replaced with appropriate logic to handle whether or not an
apr_status_t was passed in.

Comments?
-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

Re: cvs commit: httpd-2.0/modules/http http_protocol.c

[Greg Ames]

[EMAIL PROTECTED] wrote:
> 
> jerenkrantz02/05/06 00:43:40
> 
>   Modified:.CHANGES STATUS
>include  httpd.h
>modules/http http_protocol.c
>   Log:
>   Rewrite ap_byterange_filter so that it can work with data that does not
>   have a predetermined C-L - such as data that passes through mod_include.

just tried this with my SSI/Range: test cases...I can't break it any more. 

Nice job, Justin!

Greg

Re: 1.3.26

[Jim Jagielski]

At 8:27 AM -0400 5/14/02, Jim Jagielski wrote:
>Sounds good. +1 on this. I'm curious about always failing if
>setsid() fails... We are smarter than that in 2.0...
>

Never mind... I see that's already addressed. Need to change the sorting
in my email client :)
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: 1.3.26

[Jim Jagielski]

Sounds good. +1 on this. I'm curious about always failing if
setsid() fails... We are smarter than that in 2.0...

[EMAIL PROTECTED] wrote:
> 
> >   http://www.catnook.com/patches/apache-1.3.24-daemontools.patch
> >
> > is valid. To the point, however, the bug says to simply place in
> > ./patches, but I'm wondering whether we should just fold it into
> > the official source. That's what I'm leaning towards... Any complaints
> > if, after review and test, we do that??
> 
> My intention was to review, test and fold into the core.
> 
> Dw
> 


-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: HEAD broken?

[Justin Erenkrantz]

On Tue, May 14, 2002 at 12:27:18AM -0700, Greg Stein wrote:
> -1 on the two commits.
> 
> I don't think that is right. It is entirely possible that the install
> location will NOT have the .la file. It might only have .so libs and maybe a
> .a lib.
> 
> I think the changes should be reverted, or changed as I describe below.

As usual, you're right.  =)

I've changed them to meet your description.  -- justin

Re: HEAD broken?

[Greg Stein]

On Mon, May 13, 2002 at 08:08:04PM -0700, Justin Erenkrantz wrote:
> On Mon, May 13, 2002 at 10:54:55PM -0400, Cliff Woolley wrote:
> > On Mon, 13 May 2002, Justin Erenkrantz wrote:
> > 
> > > Hmm.  We could modify apr-config to always print the la-file even
> > > if it doesn't exist yet.  Can you try this?
> > 
> > That fixed it.
> 
> Okay, I committed changes to both apr-config and apu-config so
> that they will always print the .la file information.  -- justin

-1 on the two commits.

I don't think that is right. It is entirely possible that the install
location will NOT have the .la file. It might only have .so libs and maybe a
.a lib.

I think the changes should be reverted, or changed as I describe below.

The simple answer is that Cliff had old libraries, and the link line
happened to pick them up first, in preference to the .la file from the local
build directory.

I would say that if location==build, then you can force the .la file. That
would also fix this particular case.

And the definition for --apr-la-file is empty, or the .la file. The doc
specifically states "if available". That is very important when you're
considering an installation that does not include the .la file.

For example, apr-1.0-1.i386.rpm might install *only* the .so file and its
symlinks. apr-devel would install the .a and .la files and the headers.
Thus, it would be quite reasonable and possible that a .la file does not
exist in a particular installation.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/