in reply to Re^3: [mod_perl] path_info() problem
in thread [mod_perl] path_info() problem

hey merlyn,
I'm still looking at it (saw your posting last night)... but I think I still don't understand it. Why is it so important? I mean: if I add for instance ../.. (or a lot of them) to the URI, it doesn't do a thing. I mean, eventually it just shows the document_root. (and not some directory which should be protected by the webserver).

And, I want to parse files and directories (because: I want to create a small file-browser which can handle text files and images. The images i want to display, and for the text files i want a minimal syntax highlighting display).. so if I add that line 95 to my code (maybe on the wrong spot in my code), I also have to add a slash to my files. Is that normal? I mean: a URI like http://somehost/file.txt/ seems weird to me (but who am i)
But ok, you said: how they handle being passed a directory name.. Also: adding the DECLINE renders a "File Not Found" on my server. So if I want to use your tip, if need to add a slash at the end of each link i create (like the <a href="$location/">).
But like I said: I probably don't understand what you mean..

I've put my updated code (with the syntax highlighting mess) in my scratchpad, if someone's interested.

Either way: thank you for pointing me at stuff I read to quickly (or failed to read). It's a bad habit of me.. ack.

to ask a question is a moment of shame
to remain ignorant is a lifelong shame

Replies are listed 'Best First'.
Re^5: [mod_perl] path_info() problem
by merlyn (Sage) on May 11, 2005 at 09:59 UTC
    The basic problem is this:

    If the user requests /some/place/somedir, where somedir is a directory, and you return back a real page for that, and within that real page you place the link "file1", because you're talking about /some/place/somedir/file1, the browser will instead fetch /some/place/file1, because that's relative to the URL as presented.

    So the solution is that you never serve a page for a directory that doesn't end in a slash. If you are asked for /some/place/somedir, you send an external redirect to /some/place/somedir/, so that relative names like "file1" are in the right place.

    Now, either you can send the external redirect, or do as I did the lazy way, and simply decline the request, because mod_dir knows how to do that.

    So, if the mime type is DIR_MAGIC_TYPE, and the uri does not end in /, return DECLINED. That's the rule, and it's a simple rule. Do that at the top of your handler.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
      see, again i forgot to read a specific part (the DIR_MAGIC_TYPE one)..

      but i'm starting to understand it.. i think. I've read your code completely now, and I saw your separation of handle_directory() and handle_file().

      now, in my situation, the content_type method always returns undef.

      my handler now looks like this: 

      sub handler ($$) {
    my ($self,$r)= @_;
    $self = $self->new unless ref $self;
    $self->{r} = $r;
    $self->{content_type}=$r->content_type;
    $self->{uri}= $self->{r}->uri || '/';
    if ($self->{content_type} eq DIR_MAGIC_TYPE) {
        return DECLINED unless $self->{uri} =~ /\/$/;
    }

      [download]
      but it never goes in the if loop. Do you need the mime_magic module of Apache to be enabled, or not?

      Anyhow: thanks a bunch for helping me! I've just started playing with mod_perl (cuz i've just started reading "practical mod_perl"), but already I've learned a lot! Mostly by just looking at Stonehenge::Pictures. And euhm: always when i learn a new language or so, the first thing i always try to make: is a picture album/browser thing ;-)

      to ask a question is a moment of shame
      to remain ignorant is a lifelong shame

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom