httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (David Robinson)
Subject Re: vote status
Date Fri, 16 Feb 1996 16:18:00 GMT
>> 56.alias_userdir      -1
>Nice of you to be so prompt... the patch has only been there for three 
>months now.
>>   1: There is appears to be a security hole:
>>        char redirect[256];
>>        sprintf(redirect, "%s%s%s%s", x, w, userdir, dname);
>>   where dname is the rest of the URL after the ~user bit
>Hmm. True. If it were replaced with instances of pstrcat((), would that 
>be okay?


>>   These are ok, but
>>   d. UserDir http://x/users   -> (302) http://x/users/bar/one/two.html
>>   e. UserDir http://x/*/y     -> (302) http://x/bar/y/one/two.html
>>   these are too confusing. This should be provided by updating the
>>   Redirect syntax, to something like
>>   Redirect /~*
>But is there anything particuarly wrong with it? Just because you perfer 
>to use /~*, I don't think that's a good reason not to have UserDir 
>perform the function as well.
>>   Not only is it simpler, but it is also much closer to the syntax that
>>   NCSA die-hards are used to.
>By defenition, NCS dAie-hards use NCSA.

Well, Redirect /~ xxxx
redirecting /~user is feature that stop people migrating from NCSA to
Apache (like the user who mailed me yesterday). Of course, it doesn't
matter to this group whether people use Apache or NCSA... 8-)

Looking at your syntax again, it doesn't seem too bad, so maybe I could
be convinced.

>> 73a.mod_actions        1
>>   [Should this be compiled in by default, or should it be commented out of
>>    Configuration?]
>Compiled in. That's why the patch adds itself to the Configration. Just 
>so we'd be clear :)

Err, yes. But I wasn't asking you; I was asking the rest of the group.

>> 90g.keepalive          0 [but I'd like to give -1]
>> Problems: it doesn't free memory between requests because it preserves
>> data from earlier requests; this is wrong as HTTP is meant to be stateless
>HTTP is stateless, the server is not. It's entirely conceivable that 
>someone may want to write a module that logs the way peristent 
>connections are used, or that a future version of the HTTP protocol (for 
>example, Alex Hopmann's session extension draft) will involve the use of 
>data from previous connections.

The use of some data, yes, but not every bit of memory used by the last
request. It hurts performace.

If some module needs to save data over requests, then it can already.


View raw message