Distributed Development Research
(Sorry for the off-topic post - it was suggested to me that I post here and see if there was any interest...) Hi - I'm a CS researcher who does research in groupware and distributed systems. I'm writing because I would like to interview some httpd developers to find out how people in distributed open-source projects manage to stay aware of others on the project. By 'awareness' I mean things like who is on the project, who is the person to talk to for particular issues, who to inform when you want to make a particular change, and so forth. I've found some surprising things so far talking with some people from the NetBSD project - I'd like to see how things are done here on httpd. There's a longer description of my project below - if you would be willing to talk about your experiences with me, please send email to [EMAIL PROTECTED] (or reply to this message, or whatever). Thanks, Carl Group awareness in distributed development projects == It is not obvious how open-source projects manage to coordinate the efforts of numerous developers, all with write access to the code. Although projects are usually partitioned to reduce the people working in any one area, there are still many cases where one person's actions are dependent on, or will affect, another person's work. I am trying to find out how developers stay aware of who's doing what - e.g.: - who is in charge of (or is currently working on) piece X? - who should I inform before making a change? - is anyone already working on change Z? - is person Y nearly finished their work on change Z? - how do new developers 'learn the ropes' of who does what on the project? - are there situations where work is duplicated or people work at cross purposes (i.e. where there was inadequate awareness)? I would like to collect information from you about these issues, about other awareness problems, or about how things work on this project. If you would be willing to discuss it further, please contact me at [EMAIL PROTECTED] === -- Carl Gutwin, Associate Professor, Department of Computer Science University of Saskatchewan, 57 Campus Drive, Saskatoon SK S7N 5A9 Tel: (306) 966-8646 Fax: (306) 966-4884WWW: hci.usask.ca
Re: 1.x: byte-range with ErrorDocuments returns incorrect status code
Will Lowe wrote: > Thanks for the quick response -- sorry I've been slow getting back to > you. Yes, the attached patch does seem to fix 1.3.X. It'd be great if > it got rolled into the next point release. ok, I'll try and guide it through the process. --Geoff
mod_ssl TLS/SSL upgrade...
I would like to resurrect an old discussion. About a year and half ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine upgrade capability. It seems that one of the reasons for not back porting it to the 2.0 tree was because there weren't really any clients that supported it. Well I know of at least one now which is Novell's iPrint client and I suspect that there may be others out there. Does anyone see any major issues with backporting this functionality to 2.0? If not then I would like to propose it for back port and see if we can get it done. The attached patch can be applied to the 2.0 branch. HEAD already contains all of the patches. Here (http://www.apache.org/~bnicholes/wget_tls_prelim-1.8.2.tar.gz)is a hacked version of wget that is able to test the functionality. Invoke wget with the -u parameter to allow it to request the TLS/SSL upgraded connection. Brad At 11:46 AM 10/15/2002, [EMAIL PROTECTED] wrote: [snip] >The second is SSL upgrade. I have the patches, they haven't been >committed yet. I have attached them at the bottom of this message. The >reason they haven't been committed, is that I don't have a client to test >them with, and I haven't had time to create one. The responses are >correct I have checked them in plain text. The place that bugs most >likely exist, is the actual upgrade code that does the handshake. This is >an important feature, and I would really like to see it in 2.0. I see a couple of very important aspects to this patch: 1) we must have an implementation of connection: upgrade for libwww, since that is the mechanism we use for httpd-test/perl-framework. I don't have such a fix, so I'm just asking the community if anyone has explored that avenue. 2) it has to be maintained. I've looked at this patch, it appears quite correct. I'm going to begin working on applying it to cvs HEAD. I'm not concerned about it quickly appearing in 2.0 since there are no clients right now. I'm much more concerned about it's availability once clients can support it. 3) right now, the ssl code (ssl_engine_io) was already pretty heavily refactored. The patch wasn't easy to apply. We are discussing other refactorings that will make SSL much simpler to follow and far less error-prone. Those will effectively invalidate the effort Ryan has already invested. My proposed solution is to review the patch and apply it to cvs HEAD. Get it committed. Of course there are no test suites right now, and there won't be for a little while yet. But once the code exists, it will be simpler to keep the SSL upgrade facility maintained, and debug it as the clients become available (most especially, libwww exercises through perl-framework.) Any disagreement? The current patch that applies to cvs HEAD is attached. Bill Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com ssl-upgrade.patch Description: Binary data
Re: patch bug # 19271
On Thu, Mar 04, 2004 at 01:48:15PM -0500, Aryeh Katz wrote: > I'm not quite sure how to submit a patch to bugzilla, so can someone > please take care of the following for me. > In addition, and corrections/better ways would be greatly appreciated. That one is actually fixed on HEAD though ab's SSL support is still pretty... unreliable. The diff between ab.c in 2.0.48 and HEAD is here: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/support/ab.c?r1=1.137&r2=1.121.2.4 joe
Re: 1.x: byte-range with ErrorDocuments returns incorrect status code
Thanks for the quick response -- sorry I've been slow getting back to
you. Yes, the attached patch does seem to fix 1.3.X. It'd be great if
it got rolled into the next point release.
On Thu, Feb 26, 2004 at 09:18:02AM -0500, Geoffrey Young wrote:
>
>
> Will Lowe wrote:
> > It looks like byte-range requests on non-existant files returns 206
> > instead of 404 if ErrorDocument is set.
>
> I was able to verify this - it looks like there's some simple logic in 2.0
> that wasn't carried over to 1.3.
>
> so, try this patch. all the byterange tests in the perl-framework pass with
> it, in addition to my own ErrorDocument tests that I used to reproduce the
> problem.
>
> if anyone on 1.3 support is paying attention, what's the proper course for
> insertion into the stable tree once things are verified - add to STATUS and
> wait for reviews/votes?
>
> --Geoff
> Index: src/main/http_protocol.c
> ===
> RCS file: /home/cvspublic/apache-1.3/src/main/http_protocol.c,v
> retrieving revision 1.332
> diff -u -r1.332 http_protocol.c
> --- src/main/http_protocol.c 16 Feb 2004 22:29:33 - 1.332
> +++ src/main/http_protocol.c 26 Feb 2004 14:14:21 -
> @@ -260,7 +260,7 @@
> if (!(range = ap_table_get(r->headers_in, "Range")))
> range = ap_table_get(r->headers_in, "Request-Range");
>
> -if (!range || strncasecmp(range, "bytes=", 6)) {
> +if (!range || strncasecmp(range, "bytes=", 6) || r->status != HTTP_OK) {
> return 0;
> }
> range += 6;
--
thanks,
Will
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 01:33 PM 3/4/2004, William A. Rowe, Jr. wrote: At 12:04 PM 3/4/2004, Greg Marr wrote: >At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote: >>At 09:55 AM 3/4/2004, Greg Marr wrote: >> >>>/incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. >> >>uh wrong. with /debug incremental yes is the default but you have >>to pound it into the msdev's head. please fix/revert. >> > -# ... /dll /incremental:no /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref > +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref ... > >Odd, I thought non-incremental was the default, but the help says otherwise. Incremental is the default, for regular and debug, at least in VC6. > >Why would you not want incremental for a debug build anyway? Greg we are creating the release build there - we create a pdb for unwinding core dumps. Oh, duh. Yeah. It is an optimized binary - incremental is not a healthy way to release a final image. Again, please revert. I would if I could... I was just commenting on why I thought it happened.
Re: buffer overflow in ab.c
Sander Temme wrote: One more thing. Can someone explain this SSL bit for me? This seems to be an uninit var invocation for pollresults? const apr_pollfd_t *pollresults; -snip if (ssl == 1) status = APR_SUCCESS; else #endif status = apr_pollset_poll(readbits, aprtimeout, &n, &pollresults); You mean this one? You're passing the pointer by reference, so apr_pollset_poll() can fill it in. It should return a valid array of n apr_pollfd_t structures. I see that my snipping was too effective :). Actually, this was bug 19271, which I've submitted a patch for. In the ssl case, pollresults was never initialized, and we'd then try to set next_fd to the value of pollresults[i], which causes ab to crash. Aryeh S. -- Aryeh Katz SecureD Services http://www.secured-services.com/ 410 653 0700 x 2
Re: making filters more efficient
Greg Stein wrote: On Tue, Mar 02, 2004 at 10:11:06AM -0800, Stas Bekman wrote: Justin Erenkrantz wrote: ... Correct. Because the EOS is generated by the request-level protocol handler (HTTP_IN). That's exactly how it is designed. If a connection input filter saw EOS, it'd signal end-of-connection not end-of-request. But, we don't even have EOC yet - Madhu's adding it for mod_ssl's purposes for the output chain. That sounds very incosistent. Why connection output filters do get the EOS bucket at the end of every HTTP request (which makes them HTTP aware, no?), but their brother input filters don't? Why it is not a problem with connection output filters? The output filters see EOS as "end of response", and that information is useful at all levels. The input filters see EOS in different ways because of where they are in the semantic level of parsing. At the connection level, there is no such thing as a request, so EOS can only mean "end of connection". At the request level, an EOS has the meaning of "end of request". Any chance someone can document all that? The current state of the filters internals documentation at http://httpd.apache.org/docs-2.0/ is 'nada'. Please correct me if I'm wrong. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: making filters more efficient
Geoffrey Young wrote: If you have a concrete example of something that needs to query the state, then we can examine whether it should hook into the processing differently. I bet there is a different hook or approach that can avoid a query of the state. I think where stas is headed are cases like ryan's mod_apachecon http://rkbloom.net/rbb/mod_apachecon.c which seems to be to be a valid example - you want to manipulate part of the HTTP request, such as the request line or incoming headers, and post-read is too late. but simply scaning input for GET .* HTTP/1.0 isn't sufficient, since it's not foolproof, so it would be nice to have something that signaled the start of a request. Yes, that's exactly the case I'm talking about. Thanks Geoff. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: buffer overflow in ab.c
> One more thing. > Can someone explain this SSL bit for me? > This seems to be an uninit var invocation for pollresults? > > const apr_pollfd_t *pollresults; > -snip >if (ssl == 1) >status = APR_SUCCESS; >else > #endif > status = apr_pollset_poll(readbits, aprtimeout, &n, &pollresults); You mean this one? You're passing the pointer by reference, so apr_pollset_poll() can fill it in. It should return a valid array of n apr_pollfd_t structures. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
patch bug # 19271
I'm not quite sure how to submit a patch to bugzilla, so can someone
please take care of the following for me.
In addition, and corrections/better ways would be greatly appreciated.
# diff -u ab.old.c ab.c
--- ab.old.cThu Mar 4 12:32:21 2004
+++ ab.cThu Mar 4 13:44:39 2004
@@ -1699,8 +1699,13 @@
}
for (i = 0; i < n; i++) {
+#ifdef USE_SSL
+const apr_pollfd_t *next_fd;/* unint - INTENTIONAL */
+struct connection *c = &con[i];
+#else
const apr_pollfd_t *next_fd = &(pollresults[i]);
struct connection *c = next_fd->client_data;
+#endif
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 12:04 PM 3/4/2004, Greg Marr wrote: >At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote: >>At 09:55 AM 3/4/2004, Greg Marr wrote: >> >>>/incremental:no is the default, and MSDev will at times remove flags that it finds >>>redundant, even ones that it added itself. It's a bit schizophrenic like that. >> >>uh wrong. with /debug incremental yes is the default but you have >>to pound it into the msdev's head. please fix/revert. >> > -# ... /dll /incremental:no /debug /machine:I386 > /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref > +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll > /opt:ref ... > >Odd, I thought non-incremental was the default, but the help says otherwise. >Incremental is the default, for regular and debug, at least in VC6. > >Why would you not want incremental for a debug build anyway? Greg we are creating the release build there - we create a pdb for unwinding core dumps. It is an optimized binary - incremental is not a healthy way to release a final image. Again, please revert. Bill
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote: At 09:55 AM 3/4/2004, Greg Marr wrote: >/incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. >>> -# ... /dll /incremental:no /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>> +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>... Odd, I thought non-incremental was the default, but the help says otherwise. Incremental is the default, for regular and debug, at least in VC6. Why would you not want incremental for a debug build anyway?
Re: buffer overflow in ab.c
One more thing.
Can someone explain this SSL bit for me?
This seems to be an uninit var invocation for pollresults?
const apr_pollfd_t *pollresults;
-snip
if (ssl == 1)
status = APR_SUCCESS;
else
#endif
status = apr_pollset_poll(readbits, aprtimeout, &n, &pollresults);
if (status != APR_SUCCESS)
apr_err("apr_poll", status);
if (!n) {
err("\nServer timed out\n\n");
}
for (i = 0; i < n; i++) {
const apr_pollfd_t *next_fd = &(pollresults[i]);
# diff -u ab.old.c ab.c
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2
Re: mod_jk / mod_jk2 : help from specialists welcome
Henri Gomez wrote: > Justin Erenkrantz wrote: > >> --On Wednesday, March 3, 2004 12:24 PM +0100 Henri Gomez >> <[EMAIL PROTECTED]> wrote: >> >>> To resume you : >>> >>> - remove translate >>> >>> - move translate code to map_storage >>> >>> Did I understand correctly ? >> >> >> >> Yes, I think that'll work. -- justin > > > Ok, Jean-Frederic is working on what you suggest, but still have problems : > > jfclere 2004/03/03 09:55:32 > > Modified:jk/native2/server/apache2 mod_jk2.c > Log: > Remove jk2_translate... It is still not 100% OK: > - LocationMatch does not work. > - Some _not_found ends in Tomcat when using mod_dav. > > And now mod_dav off httpd-2.1 tells: +++ [Thu Mar 04 18:45:18 2004] [crit] [client 172.25.182.35] configuration error: couldn't check access. No groups file?: /examples/jsp-source/ +++ I have in httpd.conf: +++ Dav On AuthType Basic AuthName DAV AuthUserFile user.passwd AuthGroupFile user.group # ForceType text/plain #require user admin Require valid-user +++ Is there something wrong in my configuration? Cheers Jean-Frederic signature.asc Description: OpenPGP digital signature
buffer overflow in ab.c
Not to mention the k&r calling convention...
# diff -u ab.old.c ab.c
--- ab.old.cThu Mar 4 12:32:21 2004
+++ ab.cThu Mar 4 12:32:52 2004
@@ -558,6 +558,7 @@
BIO *bio;
X509 *x509cert;
{
+#define BUFSIZE 64
X509_NAME *dn;
char buf[64];
dn=X509_get_issuer_name(x509cert);
-X509_NAME_oneline(dn, buf, BUFSIZ);
+X509_NAME_oneline(dn, buf, BUFSIZE-1);
BIO_printf(bio,"The issuer name is %s\n", buf);
dn=X509_get_subject_name(x509cert);
-X509_NAME_oneline(dn, buf, BUFSIZ);
+X509_NAME_oneline(dn, buf, BUFSIZE-1);
BIO_printf(bio,"The subject name is %s\n", buf);
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 09:55 AM 3/4/2004, Greg Marr wrote: >/incremental:no is the default, and MSDev will at times remove flags that it finds >redundant, even ones that it added itself. It's a bit schizophrenic like that. uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. >>> -# ... /dll /incremental:no /debug /machine:I386 >>> /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>> +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll >>> /opt:ref >>...
Re: "(97)Address family not supported by protocol" causes "disk ticking"?
On Sat, Feb 21, 2004 at 11:00:25AM +, Alexis Huxley wrote: > I'm running apache 2.1dev, and I've posted to the -user list with > no response, so now I'm a bit stuck as to where next to try, so I'm > posting here. Apologies if this is the wrong place. The bug is that the POD code is doing a name lookup on the first bound address, which doesn't seem to make much sense since the addresses of bound listeners are determined just before the POD is opened. It breaks on Linux systems where getaddrinfo will return AF_INET6 addresses but socket(AF_INET6...) fails. There's also some interaction with the new alloc_listener logic on HEAD I presume since nobody has complained about this with 2.0, not quite sure there. One-liner is below, proper fix is to remove the sa field from ap_pod_t and always use ap_listeners->bind_addr in its place, which I'll do unless anyone can think of a good reason to do a name lookup here. Index: server/mpm_common.c === RCS file: /home/cvs/httpd-2.0/server/mpm_common.c,v retrieving revision 1.117 diff -u -r1.117 mpm_common.c --- server/mpm_common.c 25 Feb 2004 11:55:31 - 1.117 +++ server/mpm_common.c 4 Mar 2004 16:39:48 - @@ -366,8 +366,7 @@ apr_file_pipe_timeout_set((*pod)->pod_in, 0); (*pod)->p = p; -apr_sockaddr_info_get(&(*pod)->sa, ap_listeners->bind_addr->hostname, - APR_UNSPEC, ap_listeners->bind_addr->port, 0, p); +(*pod)->sa = ap_listeners->bind_addr; /* close these before exec. */ apr_file_inherit_unset((*pod)->pod_in);
RE: [PATCH] RewriteCond and SSL environment variables
> -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED] [SNIP] > > I'm not familiar with mod_ssl internals, but is there any > reason we can't > move subprocess_env population to something early like > post-read-request? > as a per-connection thingy, HTTPS ought to be know before the > request cycle > begins, right? maybe not for other things, though... +1. I don't see any harm in making the HTTPS available in the subprocess_env soon after read_request. (Infact, I think we *should* do it that way) -Madhu
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 09:09 AM 3/4/2004, Joe Orton wrote: On Mon, Mar 01, 2004 at 05:49:52PM -, [EMAIL PROTECTED] wrote: > ake 2004/03/01 09:49:52 > > Modified:.libhttpd.dsp > Log: > add eoc_bucket.c to project I'm not qualified to review Win32 changes but did you mean to remove /incremental:no from the linker flags here as well as adding eoc_bucket.c? Can you add this change to the list of changes to include in the EOC bucket backport if it is really OK to backport for 2.0? /incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. > -# ... /dll /incremental:no /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref > +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref ...
Re: making filters more efficient
> If you have a concrete example of something that needs to query the state, > then we can examine whether it should hook into the processing > differently. I bet there is a different hook or approach that can avoid a > query of the state. I think where stas is headed are cases like ryan's mod_apachecon http://rkbloom.net/rbb/mod_apachecon.c which seems to be to be a valid example - you want to manipulate part of the HTTP request, such as the request line or incoming headers, and post-read is too late. but simply scaning input for GET .* HTTP/1.0 isn't sufficient, since it's not foolproof, so it would be nice to have something that signaled the start of a request. --Geoff
Re: [PATCH] RewriteCond and SSL environment variables
> Maybe
> we should put the HTTPS check into an own function (we could use %{HTTPS} in
> mod_rewrite then). That way, other modules, that want to check (only) HTTPS,
> also don't need to run though all the mess of ssl_var_lookup.
I'm not familiar with mod_ssl internals, but is there any reason we can't
move subprocess_env population to something early like post-read-request?
as a per-connection thingy, HTTPS ought to be know before the request cycle
begins, right? maybe not for other things, though...
anyway, this same thing came up recently with mod_env
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=107655981117848&w=2
in that case I did trace the code and couldn't see any reason that the
population couldn't appear sooner, other than perhaps the history of
subprocess_env (but I haven't been around _that_ long :)
--Geoff
Re: cvs commit: httpd-2.0 libhttpd.dsp
On Mon, Mar 01, 2004 at 05:49:52PM -, [EMAIL PROTECTED] wrote: > ake 2004/03/01 09:49:52 > > Modified:.libhttpd.dsp > Log: > add eoc_bucket.c to project I'm not qualified to review Win32 changes but did you mean to remove /incremental:no from the linker flags here as well as adding eoc_bucket.c? Can you add this change to the list of changes to include in the EOC bucket backport if it is really OK to backport for 2.0? > -# ... /dll /incremental:no /debug /machine:I386 > /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref > +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll > /opt:ref ...
Re: making filters more efficient
On Tue, Mar 02, 2004 at 10:11:06AM -0800, Stas Bekman wrote: > Justin Erenkrantz wrote: >... > > Correct. Because the EOS is generated by the request-level protocol > > handler (HTTP_IN). That's exactly how it is designed. If a connection > > input filter saw EOS, it'd signal end-of-connection not end-of-request. > > But, we don't even have EOC yet - Madhu's adding it for mod_ssl's > > purposes for the output chain. > > That sounds very incosistent. Why connection output filters do get the EOS > bucket at the end of every HTTP request (which makes them HTTP aware, no?), > but their brother input filters don't? Why it is not a problem with connection > output filters? The output filters see EOS as "end of response", and that information is useful at all levels. The input filters see EOS in different ways because of where they are in the semantic level of parsing. At the connection level, there is no such thing as a request, so EOS can only mean "end of connection". At the request level, an EOS has the meaning of "end of request". >... > > There's been no data written by the time the response handler is > > called. So, the handler can always set the headers before it does the > > first write. Once a write is triggered, you must assume that the > > headers are sent. And, that's (almost) how it was in 1.3 as well. -- > > justin Agreed. [and with Justin's other responses on this thread] > There are more complicated setups than just one simple script or a handler, > where it could be hard to know whether the output headers set has been sent > already or not. Granted that setup could write their own flag, which the rest > of the application could use, but it sounds ideal for Apache to provide a set > of state functions, which can tell you what exactly Apache is doing, whether > it has completed something (sent headers) or has not completed (e.g. still > parsing headers). If code needs to *query* to figure out what is going on, then I would posit that it has not been correctly hooked into the Apache processing. If you have a concrete example of something that needs to query the state, then we can examine whether it should hook into the processing differently. I bet there is a different hook or approach that can avoid a query of the state. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [PATCH] RewriteCond and SSL environment variables
On Thu, Mar 04, 2004 at 11:08:25AM +0100, André Malo wrote:
> * Joe Orton <[EMAIL PROTECTED]> wrote:
>
> > I'm not really convinced about using ssl_var_lookup_ssl: that function
> > does not handle the "HTTPS" variable, and it would be potentially
> > confusing to users and hard to document since only some subset of the
> > SSL variables could be used. (it would also need a new optional
> > function in mod_ssl)
> >
> > I'll commit the original patch with Madhu's fix to check
> > rewrite_ssl_lookup unless there are any strong objections.
>
> Then it's time to change it. The ssl_var_lookup function is totally messy
> and _slow_.
> We want SSL variables, so let's only grab them.
>
> I'm -1 (vote not veto) on using the generic ssl_var_lookup function. Maybe
> we should put the HTTPS check into an own function (we could use %{HTTPS} in
> mod_rewrite then). That way, other modules, that want to check (only) HTTPS,
> also don't need to run though all the mess of ssl_var_lookup.
That sounds like a great idea. I still think that %{SSL:..} should use
ssl_var_lookup for consistency; sure, the function is messy and does
lots of nasty strcasecmp's but I'd really think that the overhead is
lost in the noise for an SSL connection. It's easy to optimise a few
out anyway...
Index: modules/mappers/mod_rewrite.c
===
RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_rewrite.c,v
retrieving revision 1.252
diff -u -r1.252 mod_rewrite.c
--- modules/mappers/mod_rewrite.c 9 Feb 2004 20:29:20 - 1.252
+++ modules/mappers/mod_rewrite.c 4 Mar 2004 12:27:41 -
@@ -89,6 +89,8 @@
#include "http_protocol.h"
#include "http_vhost.h"
+#include "mod_ssl.h"
+
#include "mod_rewrite.h"
#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
@@ -380,6 +382,9 @@
static apr_global_mutex_t *rewrite_log_lock = NULL;
#endif
+/* Optional functions imported from mod_ssl when loaded: */
+static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *rewrite_ssl_lookup = NULL;
+static APR_OPTIONAL_FN_TYPE(ssl_is_https) *rewrite_is_https = NULL;
/*
* +---+
@@ -1610,6 +1615,10 @@
result = getenv(var);
}
}
+else if (var[4] && !strncasecmp(var, "SSL", 3) && rewrite_ssl_lookup) {
+result = rewrite_ssl_lookup(r->pool, r->server, r->connection, r,
+var + 4);
+}
}
else if (var[4] == ':') {
if (var[5]) {
@@ -1693,6 +1702,13 @@
return (char *)result;
}
break;
+
+case 5:
+if (!strcmp(var, "HTTPS")) {
+int flag = rewrite_is_https && rewrite_is_https(r->connection);
+return apr_pstrdup(r->pool, flag ? "on" : "off");
+}
+break;
case 8:
switch (var[6]) {
@@ -3995,6 +4011,9 @@
}
}
}
+
+rewrite_ssl_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
+rewrite_is_https = APR_RETRIEVE_OPTIONAL_FN(ssl_is_https);
return OK;
}
Re: [PATCH] RewriteCond and SSL environment variables
* Joe Orton <[EMAIL PROTECTED]> wrote:
> I'm not really convinced about using ssl_var_lookup_ssl: that function
> does not handle the "HTTPS" variable, and it would be potentially
> confusing to users and hard to document since only some subset of the
> SSL variables could be used. (it would also need a new optional
> function in mod_ssl)
>
> I'll commit the original patch with Madhu's fix to check
> rewrite_ssl_lookup unless there are any strong objections.
Then it's time to change it. The ssl_var_lookup function is totally messy
and _slow_.
We want SSL variables, so let's only grab them.
I'm -1 (vote not veto) on using the generic ssl_var_lookup function. Maybe
we should put the HTTPS check into an own function (we could use %{HTTPS} in
mod_rewrite then). That way, other modules, that want to check (only) HTTPS,
also don't need to run though all the mess of ssl_var_lookup.
nd
Re: mod_jk / mod_jk2 : help from specialists welcome
Justin Erenkrantz wrote: --On Wednesday, March 3, 2004 12:24 PM +0100 Henri Gomez <[EMAIL PROTECTED]> wrote: To resume you : - remove translate - move translate code to map_storage Did I understand correctly ? Yes, I think that'll work. -- justin Ok, Jean-Frederic is working on what you suggest, but still have problems : jfclere 2004/03/03 09:55:32 Modified:jk/native2/server/apache2 mod_jk2.c Log: Remove jk2_translate... It is still not 100% OK: - LocationMatch does not work. - Some _not_found ends in Tomcat when using mod_dav.
Re: [PATCH] RewriteCond and SSL environment variables
On Thu, Mar 04, 2004 at 07:41:54AM +0100, André Malo wrote:
> * "Mathihalli, Madhusudan" <[EMAIL PROTECTED]> wrote:
>
> >
> > Here's a slightly modified version of Joe's patch to
> > - not segfault if rewrite_ssl_var_lookup is not available (mod_ssl not
> > loaded)- use SSL environment variables as %{ENV:HTTPS} or
> > %{ENV:SSL_PROTOCOL}
>
> I'd prefer the %{SSL:...} variant and using ssl_var_lookup_ssl. All other
> stuff is already available in mod_rewrite. All the "logic" in ssl_var_lookup
> is just not necessary for this purpose.
I'm not really convinced about using ssl_var_lookup_ssl: that function
does not handle the "HTTPS" variable, and it would be potentially
confusing to users and hard to document since only some subset of the
SSL variables could be used. (it would also need a new optional
function in mod_ssl)
I'll commit the original patch with Madhu's fix to check
rewrite_ssl_lookup unless there are any strong objections.
joe
Re: [PATCH] RewriteCond and SSL environment variables
On Thu, Mar 04, 2004 at 07:41:54AM +0100, André Malo wrote:
> I'd prefer the %{SSL:...} variant and using ssl_var_lookup_ssl. All other
Agreed. It makes sense to me to make a specific point out of where those
variables came from.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
