Rici Lake | 1 Sep 2004 01:49
Picon

Re: [PATCH] Corrected some problems with mod_info.c

After some struggling, I managed to get mod_info.c to work with 
mod_perl2 PerlSections.

The current version of the revised mod_info.c: 
<http://rici.ricilake.net/src/mod_info.c>
(for those who prefer looking at patches, 
<http://rici.ricilake.net/src/mod_info.diff>
was created with diff -b -u because of a largish code indent and the 
fact that the original had a mix of tabbed and non-tabbed lines; the 
first file is detabbed).

In order to actually get this to work with mod_perl, a small patch to 
mod_perl is also
required <http://rici.ricilake.net/src/modperl.diff>. This patch uses 
pool userdata in
order to tunnel a pointer to the configuration tree into the innards of 
modperl, where
it can be retrieved in order to attach the configuration tree built by 
the perl section.
No memory was harmed in the creation of this patch; the mod_perl 
configuration tree
was always being built; it simply wasn't accessible. (See note below)

The mod_info.c on display has one extra feature: it accepts ?config as 
a query option;
if encountered, it dumps the entire configuration tree. It also writes 
filenames and
line numbers (both in the normal and ?config) displays; I figured that 
was maybe useful.

(Continue reading)

William A. Rowe, Jr. | 1 Sep 2004 07:40

Re: Bug 18388: cookies

At 11:53 AM 8/31/2004, Cliff Woolley wrote:
>On Tue, 31 Aug 2004, Jim Jagielski wrote:
>
>> Personally, I think that if Roy said that it would
>> cause non-compliance then, unless he changed his mind,
>> that's good enough for me to veto any change that
>> would add Set-Cookie.
>
>I strongly agree.  Roy?

As Roy just stated, cookies aren't in RFC 2616.  Go ahead and
apply this fix - I understand both perspectives; cookies as
connection/session/auth data, and cookies as content metadata.  
The specification is really lacking in definition/.

Bill

Manos Moschous | 1 Sep 2004 11:40
Picon

test


test

Manos Moschous | 1 Sep 2004 12:04
Picon

transcode data before them are sent back to client...

Hi,

I am very new in this field and i need some directions.
What am i want to do is to change the mod_proxy, so as i say in the subject
to transcode(i have the code for the transcoding)
the data in the proxy (mod_proxy) module before them are sent back to
client.

Client ---> PROXY ---> SERVER
		Here<<<------SERVER

So, i need to know where exactly(inside the code of proxy_http.c) the data
are recieved(for example the index.html), before they send back to the
client.
Do the module store the data somewhere temporarily(in a file) or send them
immediately to the client?
I think that everything is happening in the ap_proxy_http_process_response()
function.
Is it right...?

Could anybody give some directions?

Thanks in advance!

Manos Moschous

Eli Marmor | 1 Sep 2004 13:09
Picon

Re: transcode data before them are sent back to client...

Manos Moschous wrote:

> I am very new in this field and i need some directions.
> What am i want to do is to change the mod_proxy, so as i say in the subject
> to transcode(i have the code for the transcoding)
> the data in the proxy (mod_proxy) module before them are sent back to
> client.
> 
> Client ---> PROXY ---> SERVER
>                 Here<<<------SERVER
> 
> So, i need to know where exactly(inside the code of proxy_http.c) the data
> are recieved(for example the index.html), before they send back to the
> client.
> Do the module store the data somewhere temporarily(in a file) or send them
> immediately to the client?
> I think that everything is happening in the ap_proxy_http_process_response()
> function.

You go in the wrong direction.
Please read about Apache2 filters.
You will find a lot of information and examples in many articles, docs,
guides, and even books (such as Ryan's).
In addition, I suggest to subscribe to the modules mailing list, where
your question really belongs.

Good luck,
--

-- 
Eli Marmor
marmor <at> netmask.it
(Continue reading)

Jess Holle | 1 Sep 2004 17:04

Re: Time for 2.0.51 and 2.1.0

Sander Striker wrote:

>Hi,
>
>I'm going to start a T&R cycle for both 2.0 and 2.1 monday.
>Objections?
>
>Sander
>
>  
>
How is this going?

[Anxiously awaiting 2.0.51 tarballs...]

--
Jess Holle

Jeff Trawick | 1 Sep 2004 17:17
Picon

Re: cvs commit: httpd-2.0/server util.c

On 1 Sep 2004 15:14:33 -0000, trawick <at> apache.org <trawick <at> apache.org> wrote:
> trawick     2004/09/01 08:14:33
> 
>   Modified:    .        CHANGES
>                server   util.c
>   Log:
>   Fix the handling of URIs containing %2F when AllowEncodedSlashes
>   is enabled.  Previously, such urls would still be rejected with
>   404.

I can't see how this ever worked before :(  Any comments from the crowd?

Sander Striker | 1 Sep 2004 18:32
Picon
Favicon

Re: Time for 2.0.51 and 2.1.0

From: "Jess Holle" <jessh <at> ptc.com>
Sent: Wednesday, September 01, 2004 5:04 PM

> Sander Striker wrote:
> 
> >Hi,
> >
> >I'm going to start a T&R cycle for both 2.0 and 2.1 monday.
> >Objections?
> >
> >Sander
> >
> >  
> >
> How is this going?
> 
> [Anxiously awaiting 2.0.51 tarballs...]

Something got in the way.  I've got a round tuit reserved for today though ;)

Sander

Picon
Favicon

Mod-rewrite map prg's : is this intentional?


If you use rewritemaps in your httpd.conf base context and set virtual
hosts to inherit the rewrite options, it causes it to spawn addition
instances of the program for each virtual host.

Is there a reason it can't reuse the base contexts pipes to these
rewrite programs?

Byron

Joe Orton | 1 Sep 2004 19:27
Picon
Favicon

Re: Time for 2.0.51 and 2.1.0

On Wed, Sep 01, 2004 at 06:32:12PM +0200, Sander Striker wrote:
> Something got in the way.  I've got a round tuit reserved for today though ;)

Would be good if you could pick up the tip of the APR/-util 0.9 branches
to avoid the build failures on the revisions you tagged.

joe


Gmane