-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Rolsky wrote: > On Wed, 8 Feb 2006, Jason Thaxter wrote: >> That line is trying to set $r->content_type(undef) because >> $self->decline_dirs... > > Sounds like a bug. Maybe we should set the content type to "", not undef.
That line occurs inside "_request_fs_type". This method is commented as
following:
# If filename is a directory, then either decline or simply reset
# the content type, depending on the value of decline_dirs.
The magic word is "reset". Why resetting something that was IMHO
designed well enough? Lemme explain: "reset" makes me presume it's
referring to Apache's behavior - if $is_dir then it sets content_type to
DIR_MAGIC_TYPE.
So, "_request_fs_type" is in fact quite useless from it's caller's
("prepare_request") point of view:
my $fs_type = $self->_request_fs_type($r);
return DECLINED if $fs_type eq 'dir' && $self->decline_dirs;
Can be replaced with:
if ($r->content_type eq DIR_MAGIC_TYPE && $self->decline_dirs) {
return DECLINED;
}
Yep, I noticed $fs_type is used once more in the resolver's error
handling (still in "prepare_request", the "unless" block):
my $pathname = $r->filename;
$pathname .= $r->path_info unless $fs_type eq 'file';
But that again can be safely simplified to:
my $pathname = $r->filename . $r->path_info;
(Or maybe to:
my $pathname = $r->filename . ( $r->path_info || q{} );
for paranoid clarity)
Why? Because at this point (resolver failed) $fs_type doesn't matter
anymore (we're still going to NOT_FOUND) so the more complete warning
message is, the better it gets. ;-)
- --
Marius Feraru
-----BEGIN PGP SIGNATURE-----
iD8DBQFD6xf8tZHp/AYZiNkRArLRAJ9/bqxy1gcOpqngiDIvz2XUEfV3NwCfUMcU
2GLFDJl78jIB/zHLvkxY0ew=
=p9FN
-----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
