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

I still don't see anything addressing my second concern. You might want to look in to that.

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

Replies are listed 'Best First'.
Re^4: [mod_perl] path_info() problem
by insaniac (Friar) on May 11, 2005 at 08:37 UTC
    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

      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.

        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} =~ /\/$/; }
        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