Configurable search field and subdirectory usage support

Create issue
Issue #3 resolved
ggrundik created an issue

Please accept my patch, which adds two enhancements:

  • it adds configuration value GridFSCollectionField, which allows to change search field (default is "filename")

  • it allows module to be set up in subdirectory, using only part of url after the last slash for search

Comments (16)

  1. Aristarkh Zagorodnikov repo owner

    The new subdirectory processing code breaks existing functionality (files named "path/to/file.ext" are supported now and won't be supported if this patch is added), so I don't think this design should be used at all. There is limited support for custom prefixes using context-aware settings (Location tag), thanks to wingrunr21's patch (see changesets 9c26d8ffd0f2 and df33f5a356ad), maybe you can use this functionality to get the desired behavior.

    While the alternate name for the field that is used to search the files collection does not violate the GridFS specification by itself, I don't see much use of it, especially since it's limited to strings. Also, your specific implementation does not properly handle the case when read preference mode is specified. While I certainly understand that you may need a custom schema, your own fork with a separate branch would be better than patching this into the mainline as you will retain your private changes, but still get to merge improvements and fixes as needed.

    Please note, that I've put this one on hold instead of rejecting, if you have better implementation and/or design for these features, I would accept them.

    TL;DR summary: Subdirectory processing -- very site-specific code so you better keep it in your fork, alternate collection field name -- fix the code and we're good to go.

  2. ggrundik reporter

    Main purpose of configurable search field, is to allow referencing files by hash, not by file name. In our environment filename is a user-choosen original name of file, so there can be multiple same-named files, and we have to use some unique (and securely random) indentifiers, such as md5 or sha1 hashes of content.

  3. Aristarkh Zagorodnikov repo owner

    As for custom prefixes -- drop here a part of your apache config and gridfs directory layout, maybe I'm misunderstanding your case.

  4. ggrundik reporter

    We have several gridfs collections (about a dosen), and I want to export some of them via apache (for test servers, as alternative for nginx-gridfs used in production nodes). So, there is a following directory layout:

    /application/ (main application files)
    /public/ (web root)
    /public/files/ (I want to map gridfs collections here)
    /public/files/SomeCollection/ (map of one collection)
    /public/files/OtherCollection/ (map of other collection)

    and gridfs collections:


    I'm placing .htaccess files in such directories:

    GridFSConnection localhost
    GridFSDatabase mongobase
    GridFSCollectionPrefix fs.SomeCollection

    This is not working, since for request '' mod_gridfs searches for file named '/files/SomeCollection/somefile.doc', not just 'somefile.doc', thus resulting 404 error. Is there a right way to strip directory prefix?

  5. ggrundik reporter

    And, as I said before, there is a need to use some more or less secure file identification scheme, such as hashes, since this exports will be public.

  6. Aristarkh Zagorodnikov repo owner

    About context mapping. Consider the following:

    <Location /myprefix>

    With this configuration, the location prefix in this case, '/myprefix', is stripped from path when querying, so the request to will serve the 'path/to/file.dat' file from GridFS. In your case you would need something along these lines: <Location /files/SomeCollection>
    GridFSPrefix fs.SomeCollection

  7. ggrundik reporter

    <Location> works fine, but its not applicable for .htaccess. But it's bearable.

    Please, consider placing such examples in the documentation.

  8. Aristarkh Zagorodnikov repo owner

    I plan to add explicit prefixes (via a custom directive) that will replace location-based context in v0.4 (since it's a breaking change).

  9. Log in to comment