On 11 dec 2013, at 22:22, Ben Reser <ben_at_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 dev_at_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):
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).
Received on 2013-12-12 15:40:15 CET