Re: r->filename.

[Ted Rolle <te...@php.net>]

I'm suggesting my thoughts on the cleaner grand scheme.

Example:

mod_foo calls mod_bar.

Called routine mod_bar checks for r->filename == NULL 10 times.

Solution:
put the r->filename == NULL check in mod_foo once before calling mod_bar
and eliminate the 10 check in mod_bar.

Percolate up.

Is this a possible solution, or do I need to get a clue?

Ted

Re: r->filename.

[Geoffrey Young <ge...@modperlcookbook.org>]

> 
> Think of "module" as something Apache calls, like mod_jk2 or mod_python 
> or mod_perl or XXX...  Apache can't very well implement checks to 
> protect those modules from crapping out on r->filename.

it might be a little late in the game for this, but I've always wanted an 
api encapsulating r->filename.

the main reason was that there are really two things of interest - 
r->filename and r->finfo - so modules that twiddle r->filename after 
translation (and map_to_storage, I guess) need to remember to update 
r->finfo as well if they want later ap_meets_decisions to be made properly.

having an api would certainly make life easier in external modules (like 
mod_perl), but I suspect would solve so of the NULL issues being raised 
here, since the checking would be done in a single place.

--Geoff

Re: r->filename.

[Geoffrey Young <ge...@modperlcookbook.org>]

> probably Apache core shouldn't change the (vague) semantics of 
> r->filename but it can provide the access functions mentioned above

heh, I guess we were typing at the same time :)

--Geoff

Re: r->filename.

[Geoffrey Young <ge...@modperlcookbook.org>]

>> if it's just a matter of tuits, I'm volunteering to put it together if 
>> a loose consensus is reached as to the design.
> 
> 
> go for it!  note that any patches should be against 2.1-dev first...  we 
> can decide how much can go to stable tree later
> 

cool.  so I guess I'll just expose an API first, based on the loose specs 
you and I jotted down.  porting modules or core to use it will be a second step.

I'll report back soonish with something :)

--Geoff

Re: r->filename.

[Jeff Trawick <tr...@attglobal.net>]

Geoffrey Young wrote:

>> probably Apache core shouldn't change the (vague) semantics of 
>> r->filename but it can provide the access functions mentioned above
>>
>> modules for 2.0 that look at r->filename could call 
>> ap_request_filename() or ap_request_filename_str() depending on the 
>> requirement (dumb logging code would just call _str() version)
> 
> 
> so I take it that the resulting silence means that nobody here is 
> interested in an API wrapper?
> 
> if it's just a matter of tuits, I'm volunteering to put it together if a 
> loose consensus is reached as to the design.

go for it!  note that any patches should be against 2.1-dev first...  we can 
decide how much can go to stable tree later

RE: r->filename.

[Sander Striker <st...@apache.org>]

> From: Geoffrey Young [mailto:geoff@modperlcookbook.org]
> Sent: Tuesday, October 28, 2003 7:54 PM

> > probably Apache core shouldn't change the (vague) semantics of 
> > r->filename but it can provide the access functions mentioned above
> > 
> > modules for 2.0 that look at r->filename could call 
> > ap_request_filename() or ap_request_filename_str() depending on the 
> > requirement (dumb logging code would just call _str() version)
> 
> so I take it that the resulting silence means that nobody here is interested 
> in an API wrapper?
>
> if it's just a matter of tuits, I'm volunteering to put it together if a 
> loose consensus is reached as to the design.

Tuits I would say.

Sander

Re: r->filename.

[Geoffrey Young <ge...@modperlcookbook.org>]

> probably Apache core shouldn't change the (vague) semantics of 
> r->filename but it can provide the access functions mentioned above
> 
> modules for 2.0 that look at r->filename could call 
> ap_request_filename() or ap_request_filename_str() depending on the 
> requirement (dumb logging code would just call _str() version)

so I take it that the resulting silence means that nobody here is interested 
in an API wrapper?

if it's just a matter of tuits, I'm volunteering to put it together if a 
loose consensus is reached as to the design.

--Geoff

Re: r->filename.

[Nick Kew <ni...@webthing.com>]

> how about something like
>
> ap_request_filename(r) that returns ptr to filename or NULL

Hmmm ... ap_request_filename(r, dflt) ?

Now, this discussion bothers me.  Surely, for a module to use
r->filename when it might be unset is broken, and should be fixed
properly rather than left (potentially) to fail silently?

> probably Apache core shouldn't change the (vague) semantics of r->filename but
> it can provide the access functions mentioned above

Would it be less error-prone to call it something different?
Like ap_path_translated(r), for instance?

> modules for 2.0 that look at r->filename could call ap_request_filename() or
> ap_request_filename_str() depending on the requirement (dumb logging code would
> just call _str() version)

Even dumb logging code might be better with a printable placeholder,
yesno?

-- 
Nick Kew

Re: r->filename.

[Jeff Trawick <tr...@attglobal.net>]

Glenn wrote:

> On Sat, Oct 25, 2003 at 11:33:35AM -0700, Stas Bekman wrote:
> 
>>Ted Rolle wrote:
>>[...]
>>
>>>The calling module has the responsibility of providing a good r->filename,
>>>even when it's not used.
>>
>>what's a good r->filename? /dev/null sounds good to me.
> 
> 
> How about "" as in the empty string containing only the '\0' character?
> This way, filters after the trans_hook could be sure that r->filename
> is never NULL and at the same time, any stat calls on "" will fail.
> Smarter modules would be able to check
>   if (*r->filename != '\0') {
>       ....
>   }
> and modules that require a mapping to the filesystem could quickly do
>   if (*r->filename == '\0') {
>       return DECLINED;
>   }
> to simply decline when they detect that there is no filesystem mapping.

how about something like

ap_request_filename(r) that returns ptr to filename or NULL

ap_request_filename_str(r) that returns ptr to filename or ""

ap_request_filename_set(r, filename) that takes NULL or real filename and does 
the right thing under the covers

Apache >= 2.1 changes name of r->filename field to r->private_filename
Apache >= 2.1 makes sure r->private_filename is set sanely (whatever that is) 
after translate name hook

as far as Apache 2.0...  there are modules that set r->filename to something 
even when it makes no sense...  there are modules that set it to NULL... 
probably modules that expect r->filename==NULL to mean something

probably Apache core shouldn't change the (vague) semantics of r->filename but 
it can provide the access functions mentioned above

modules for 2.0 that look at r->filename could call ap_request_filename() or 
ap_request_filename_str() depending on the requirement (dumb logging code would 
just call _str() version)

Re: r->filename.

[Glenn <gs...@gluelogic.com>]

On Sat, Oct 25, 2003 at 11:33:35AM -0700, Stas Bekman wrote:
> Ted Rolle wrote:
> [...]
> >The calling module has the responsibility of providing a good r->filename,
> >even when it's not used.
> 
> what's a good r->filename? /dev/null sounds good to me.

How about "" as in the empty string containing only the '\0' character?
This way, filters after the trans_hook could be sure that r->filename
is never NULL and at the same time, any stat calls on "" will fail.
Smarter modules would be able to check
  if (*r->filename != '\0') {
      ....
  }
and modules that require a mapping to the filesystem could quickly do
  if (*r->filename == '\0') {
      return DECLINED;
  }
to simply decline when they detect that there is no filesystem mapping.

Cheers,
Glenn

> I believe if you want to make fix-it-behind-the-scenes for all, httpd needs 
> to check whether r->filename is set after trans_hook is done, and if it's 
> NULL, set it to that good filename. Hopefully none of the following hooks 
> will try to use that good filename for anything. The fact that we get the 
> segfault is that it *is* being used when it shouldn't (since there is no 
> corresponding filename for the virtual resource), so it's the right thing 
> to check for r->filename not being NULL before trying to use it.

Re: r->filename.

[Stas Bekman <st...@stason.org>]

Ted Rolle wrote:
[...]
> The calling module has the responsibility of providing a good r->filename,
> even when it's not used.

what's a good r->filename? /dev/null sounds good to me.

I believe if you want to make fix-it-behind-the-scenes for all, httpd needs to 
check whether r->filename is set after trans_hook is done, and if it's NULL, 
set it to that good filename. Hopefully none of the following hooks will try 
to use that good filename for anything. The fact that we get the segfault is 
that it *is* being used when it shouldn't (since there is no corresponding 
filename for the virtual resource), so it's the right thing to check for 
r->filename not being NULL before trying to use it.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: r->filename.

[Ted Rolle <te...@php.net>]

Please don't shut up...

I just <gasp!> looked at the request_rec structure.

So, it's possible that the called module may not even use r->filename?

Then the called module has responsibility for checking r->filename.

No, scratch that...

The calling module has the responsibility of providing a good r->filename,
even when it's not used.

Am I getting warm?

> I'm thinking on a different scheme :)
>
> Think of "module" as something Apache calls, like mod_jk2 or mod_python or
> mod_perl or XXX...  Apache can't very well implement checks to protect those
> modules from crapping out on r->filename.
>
> I'll shut up now.
>

Re: r->filename.

[Jeff Trawick <tr...@attglobal.net>]

Ted Rolle wrote:

> I'm suggesting my thoughts on the cleaner grand scheme.

I'm thinking on a different scheme :)

> 
> Example:
> 
> mod_foo calls mod_bar.
> 
> Called routine mod_bar checks for r->filename == NULL 10 times.
> 
> Solution:
> put the r->filename == NULL check in mod_foo once before calling mod_bar
> and eliminate the 10 check in mod_bar.

Think of "module" as something Apache calls, like mod_jk2 or mod_python or 
mod_perl or XXX...  Apache can't very well implement checks to protect those 
modules from crapping out on r->filename.

I'll shut up now.