On 11 dec 2013, at 22:22, Ben Reser <b...@reser.org> wrote: > On 12/11/13 10:45 AM, Ben Reser wrote: >> Hmm this is going to be a pain to fix (possibly impossible). Because what >> mod_rewrite is doing is really hackish. When you use the PT (PassThrough) >> flag >> mod_rewrite puts passthrough:/my/new/URL into r->filename. Then eventually >> it >> moves it to r->uri, but not until after it goes through our translate_name >> hook. So we can't reliably know if the request is going to be served by us >> or >> not by asking for the per_dir config. > > Okay this isn't strictly true. r->uri is set before it gets to us. It's just > that mod_rewrite doesn't trigger a new location walk (that happens after the > map_to_storage hooks run which is the next step after the translate_name > hook). > In order for mod_rewrite to work transparently the location_walk would need to > be triggered again.
I am not very familiar with httpd internals, but I would have expected that PT flag would cause a completely new round of translate_name and map_to_storage (i.e. one round with original url and one round with rewritten url). Have you confirmed that is not the case? If it does trigger a new round, wouldn't it be fine to just do nothing if a PT-rewrite is detected? > > We could do that on our side with something like this: ... > > But I really don't think we should for several reasons. > > First of all it starts messing with httpd internals that I don't think we > should really need to be doing. Note that I had to include the ap_if_walk() > for 2.3.x+. This sort of fix would have to forever be kept in sync with the > code in ap_process_request_internal(). Making it rather brittle. Yes, I can see your concern here. > > So at this point I think this needs to be taken to the d...@httpd.apache.org > list. I'll start a new thread over there. Thanks for looking into the matter. > None of these use cases are strictly legal. The namespace both path wise and > query argument wise belong to SVN. Overlaying your own paths or query > arguments is always going to be prone to future incompatibilities. You've > just > finally been burned. > > The right way to do what you've been doing is some other path like (where > /view > is not configured to be handled by Subversion): > http://svn.example.com/view/details/repo/folder > or > http://svn.example.com/view/repo/folder?details We see SVN as a component in a larger context. Svn is the core versioned storage of our CMS-system, where we provide a number of additional services. Keeping consistent paths significantly reduces end-user confusion and what we consider a more RESTful set of URLs. I do agree that the namespaces belong to SVN. We use a single parameter to indicate the "operation/view" and definitely not a single-letter one (we never touch the paths). A concept similar to property namespaces would be ideal, e.g. cms-view=details (or x-view=details similar to non-registered URL prefix). Thanks, Thomas Å.
