Re: mod_dav_svn changing the request filename - interaction with mod_rewrite

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):
> 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 Å.
Received on 2013-12-12 15:40:15 CET