headers
Justin Erenkrantz | 1 Mar 2004 07:03
Gravatar

Re: FreeBSD 4.x and Apache2: worker MPM issue

--On Sunday, February 29, 2004 4:06 PM -0400 "Marc G. Fournier" 
<scrappy <at> hub.org> wrote:

> k, if I'm understanding what you are saying, how do you test something
> like that in a way that you can debug it?  What I'm reading is that if I
> sent two queries (GET / and, say, GET /subdir), there is a chance that the
> one that sent GET / will get the results for GET /subdir?

No, that's not quite the problem.  It is:

1. Client requests GET /
2. *nothing happens*
3. Client (same or different) requests GET /subdir/
4. Server responds to GET / request issued in #1 (to the correct client)
5. *nothing happens*
6. Someone requests GET /subdir/foo/ issued in #3
7. Server responds to GET /subdir/ request
8. *nothing happens*
...repeat cycle...

Does this make more sense?  The server won't respond to the first request 
until the second request is issued and so on.  We think it's a flaw in how 
libc_r implements the pthread condition variables.  But, again, it's been 
fixed with the thread library rewrites in 5.2.  -- justin
Permalink | Reply | 12 comments |
headers
Justin Erenkrantz | 1 Mar 2004 07:06
Gravatar

Re: httpd.conf --> Pidfile

--On Sunday, February 29, 2004 10:11 AM -0300 Esteban Pizzini 
<eplx2002 <at> yahoo.com.ar> wrote:

>  How can I get the value of httpd.conf --> Pidfile directive from a
> module???
>  I've been looking in mod_info, but it implements a cycle reading all
> directives (and there gets PidFile value to show).. is there any function
> that gets the value of PidFile directive in a easier way??

If you include mpm_common.h, you might be able to use ap_pid_fname.  -- justin
Permalink | Reply | 0 comments |
headers
Marc G. Fournier | 1 Mar 2004 16:37
Favicon

Re: FreeBSD 4.x and Apache2: worker MPM issue

On Sun, 29 Feb 2004, Justin Erenkrantz wrote:

> --On Sunday, February 29, 2004 4:06 PM -0400 "Marc G. Fournier"
> <scrappy <at> hub.org> wrote:
>
> > k, if I'm understanding what you are saying, how do you test something
> > like that in a way that you can debug it?  What I'm reading is that if I
> > sent two queries (GET / and, say, GET /subdir), there is a chance that the
> > one that sent GET / will get the results for GET /subdir?
>
> No, that's not quite the problem.  It is:
>
> 1. Client requests GET /
> 2. *nothing happens*
> 3. Client (same or different) requests GET /subdir/
> 4. Server responds to GET / request issued in #1 (to the correct client)
> 5. *nothing happens*
> 6. Someone requests GET /subdir/foo/ issued in #3
> 7. Server responds to GET /subdir/ request
> 8. *nothing happens*
> ...repeat cycle...
>
> Does this make more sense?  The server won't respond to the first request
> until the second request is issued and so on.  We think it's a flaw in how
> libc_r implements the pthread condition variables.  But, again, it's been
> fixed with the thread library rewrites in 5.2.  -- justin

'k, this makes more sense ... but, is there no way to 'trigger' it to
debug?  As I said, I ran http_load at it, oh, wait, I wouldn't see the
problem with http_load, since, of course, its getting hit one after the
(Continue reading)

Permalink | Reply | 11 comments |
headers
Mathihalli, Madhusudan | 1 Mar 2004 19:37
Picon
Favicon

RewriteCond and SSL environment variables

Hi,
	Question: Can we use the environment variables setup by mod_ssl in the RewriteCond directive ?

I believe there's some inconsistency there - the SSL environment variables are setup in the
r->subprocess_env during the hook_fixup phase, where as the RewriteCond evaluates/expands the
environment variables during the hook_translatename phase (which happens before the hook_fixup).

As a result, the SSL variables don't get expanded on the first connection - but it happens for subsequent
connections !

-Madhu
Permalink | Reply | 6 comments |
headers
Mathihalli, Madhusudan | 1 Mar 2004 19:57
Picon
Favicon

RE: RewriteCond and SSL environment variables

BTW, I forgot to mention that RewriteCond with SSL variables work if (1) ssl_hook_Translate is
APR_HOOK_FIRST and (2) ssl_hook_Fixup logic is transferred to ssl_hook_Translate.

I know it's a hack - do you think my config is not setup correctly or is the logic wrong ?

-Madhu

-----Original Message-----
From: Mathihalli, Madhusudan 
Sent: Monday, March 01, 2004 10:38 AM
To: dev <at> httpd.apache.org
Subject: RewriteCond and SSL environment variables

Hi,
	Question: Can we use the environment variables setup by 
mod_ssl in the RewriteCond directive ?

I believe there's some inconsistency there - the SSL 
environment variables are setup in the r->subprocess_env during 
the hook_fixup phase, where as the RewriteCond 
evaluates/expands the environment variables during the 
hook_translatename phase (which happens before the hook_fixup).

As a result, the SSL variables don't get expanded on the first 
connection - but it happens for subsequent connections !

-Madhu
Permalink | Reply | 0 comments |
headers
Stas Bekman | 2 Mar 2004 05:07

EOS is not being sent for HEAD requests

in 2.0 - Connection output filters don't recieve the EOS bucket when the 
request method is HEAD. This breaks the idiom of flushing any stored data when 
the eos bucket is seen. And some filters could be broken because of that.

A typical response filter sees this for the following 3 brigades for a HEAD 
request which otherwise would have sent a response body:

 >>> connection output filter
     o bucket 1: HEAP
[HTTP/1.1 200 OK
Date: Tue, 02 Mar 2004 04:04:30 GMT
Server: Apache/2.0.49-dev (Unix) mod_perl/1.99_13-dev Perl/v5.8.3 
mod_ssl/2.0.49-dev OpenSSL/0.9.7b DAV/2
Connection: close
Content-Type: text/plain

]

 >>> connection output filter
     o bucket 1: FLUSH
[]

 >>> connection output filter
     o bucket 1: FLUSH
[]

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas <at> stason.org http://use.perl.org http://apacheweek.com
(Continue reading)

Permalink | Reply | 11 comments |
headers
Stas Bekman | 2 Mar 2004 05:18

Re: how to tell one request from another inside a connection filter over keep-alive connection

Stas Bekman wrote:
> If I'm inside an input connection filter and want to be able to tell one 
> HTTP request from another what should I do? Counting Content-length is 
> ineffective, and a won't work if C-L header is wrong.
> 
> I can tell the end of HTTP headers section from the request body, by 
> matching /^[\r\n]$/ while reading HTTP headers. But I see no token that 
> tells me that the body is done. Any filter examples I can look at?
> 
> Also, why there is no EOS token in connection level filters? if you had 
> some data buffered how do you know when to flush it?
> 
> With Keep-Alive requests I get some IMMORTAL bucket after the last 
> request. Not sure what it is. At the moment just snooping on the traffic.

Answering my own question, the solution is to use conn->keepalives counter 
which is incremented at the end of each request. By storing the previous count 
and comparing with the current count one can tell when a new request is coming 
in over the keepalive connection. This technique is now documented in the 
mod_perl land:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Filters_over_KeepAlive_Connections

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas <at> stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
Permalink | Reply | 6 comments |
headers
Stas Bekman | 2 Mar 2004 05:18

making filters more efficient

It'd be very helpful if Apache provided methods to query various in and out 
stream processing events to make filters more efficient. The events I can 
think at the moment are:

- end of HTTP input headers
- end of HTTP input body
- end of HTTP response headers
- end of HTTP response body

only the latter is sort of accessible via the EOS bucket (which as I've 
pointed out in another email is not always set!).

Ideally the connection record could have the following entries:

done_with_input_headers
done_with_input_body
done_with_output_headers
done_with_output_body

so for example when http headers processing is completed, the 
done_with_input_headers flag will go up. etc. These flags will be reset at the 
end of each request.

At the moment it's sort of possible to workout all these events from the 
filter itself, but it's *very* inefficient and makes the code fragile if 
Apache needs to change the internals. Matching for /\n\n/ on every bucket just 
to know when the headers are done with, is just plain bad, when the Apache 
core filter knows already when this event happens and it could share that 
knowledge with other filters.
(Continue reading)

Permalink | Reply | 10 comments |
headers
André Malo | 2 Mar 2004 06:26
Picon

Re: making filters more efficient

* Stas Bekman <stas <at> stason.org> wrote:

> Ideally the connection record could have the following entries:
> 
> done_with_input_headers
> done_with_input_body
> done_with_output_headers
> done_with_output_body

no other comments atm, but this isn't really ideal. The connection does not
know anything about concepts like "HTTP". (or should however).

Perhaps we should introduce a structure stub pointer for connection type
related things, private to all functions below process_*_connection.

> so for example when http headers processing is completed, the 
> done_with_input_headers flag will go up. etc. These flags will be reset at
> the end of each request.

Or should it simply be in the request struct?

nd
Permalink | Reply | 1 comment |
headers
André Malo | 2 Mar 2004 06:28
Picon

Re: EOS is not being sent for HEAD requests

* Stas Bekman <stas <at> stason.org> wrote:

> in 2.0 - Connection output filters don't recieve the EOS bucket when the 
> request method is HEAD. This breaks the idiom of flushing any stored data
> when the eos bucket is seen. And some filters could be broken because of
> that.

I believe that is because of broken handlers, which don't send anything if
they detect HEAD. In 2.0 a handler should not care about GET or HEAD, but send
all the time its data, so that all the processing (C-L filter etc) works
properly.

nd
Permalink | Reply | 10 comments |

Gmane