subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Coniguring 301/302 redirects to track an fspath rename
Date Mon, 04 Feb 2013 21:48:56 GMT
Damn, processing updates requires fishing little
details out of a REPORT request body.  This is getting
complicated...





>________________________________
> From: Joe Schaefer <joe_schaefer@yahoo.com>
>To: Greg Stein <gstein@gmail.com> 
>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>Sent: Monday, February 4, 2013 3:57 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
> 
>
>Here's the new section for the additional PROPFIND
>rewrite block:
>
>
>
>/* RewriteCond %{SUBREQ} =false                                             
*/
>/* RewriteCond %{REQUEST_METHOD}
 =PROPFIND                                   */
>/* RewriteCond %{REQUEST_URI} /repos/asf/!svn/(?:bc|rvr)/(\d+)/incubator/(.+)*/
>/* RewriteCond /repos/asf/%2?ckpath  -U                                     
*/
>/* RewriteRule .* /repos/asf/%2 [L,R=301]                                   
*/
>
>
>
>
>
>As I said it works for me with openmeetings checkouts
>out of incubator (1.6 and 1.7 clients point me at the
>new location).  I am leery tho about dorking with !svn
>based urls but these !svn/bc/$revision and !svn/rvr/$revision
>ones are nice candidates because of the embedded revision
>and path information that leads me to think I'm not too
>far off in guessing that without interception by my module
>we'd just be serving up 404's for them when they are looking
>in the incubator tree for graduated podling resources.
>
>
>
>
>
>
>>________________________________
>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>To: Greg Stein <gstein@gmail.com> 
>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>>Sent: Monday, February 4, 2013 2:44 PM
>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>> 
>>
>>Mixed news- I hacked together PROPFIND support
>>for my module and it's doing the "right thing"
>>on checkouts with 1.6 and 1.7. NFI what else this
>>breaks, but if folks could beat on incubating repos
>>for a bit to see I'd appreciate
 it.
>>
>>Thanks!
>>
>>
>>
>>
>>
>>
>>>________________________________
>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>To: Greg Stein <gstein@gmail.com> 
>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>>>Sent: Monday, February 4, 2013 1:46 PM
>>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>> 
>>>
>>>Oh damn, sigh.  I'm completely wrong- subversion doesn't
>>>serve a 404 on the OPTIONS request, even for a resource
>>>that's not present in HEAD.  It serves a 200 response,
>>>and only several PROPFIND's later do we actually serve
>>>a showstopping 404 on a checkout for a non-existent resource.
>>>
>>>That complicates this situation significantly, sorry.
>>>I don't see an immediate way to satisfy the ASF's use
>>>case given the current svn support for redirects revolves
>>>around the initial OPTIONS response not PROPFINDS.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>To: Greg Stein <gstein@gmail.com> 
>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>>>>Sent: Monday, February 4, 2013 1:30 PM
>>>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>>> 
>>>>
>>>>Please correct me if I'm mistaken, but my impression
>>>>from looking at server logs is that there are certain
>>>>cases where a 404 response to an initial OPTIONS request
>>>>is a showstopper (like a checkout or update operation),
>>>>but other times the 404 response is not a problem (like
>>>>for operations involving pegrevs).  If we can identify
>>>>this distinction and flag it somehow in the initial request
>>>>so that in the first case we ask for a non-showstopper
>>>>response from the server if available, that's all I need
>>>>to support the ASF's use case in my module.  Providing
>>>>additional version info in the query string can refine
>>>>the server response my httpd module would provide, but
>>>>that aspect is not essential to service the ASF's
 needs.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>________________________________
>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>To: Greg Stein <gstein@gmail.com> 
>>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>>>>>Sent: Monday, February 4, 2013 12:26 PM
>>>>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>>>> 
>>>>>
>>>>>How about a "prefer redirect" flag somewhere in
>>>>>the OPTIONS request?  Anything to signal to the
>>>>>server that the request wants something better
>>>>>than a 404 response it possible.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>________________________________
>>>>>> From: Greg Stein <gstein@gmail.com>
>>>>>>To: Joe Schaefer <joe_schaefer@yahoo.com> 
>>>>>>Cc: dev@subversion.apache.org 
>>>>>>Sent: Monday, February 4, 2013 7:44 AM
>>>>>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>>>>> 
>>>>>>
>>>>>>Yeah... I think the best we can do in the OPTIONS is to hint. It can't
really be more than a hint, since a connection can be used for N various operations.
>>>>>>What might be more ideal is to respect redirects after that initial
OPTIONS. Then your module could just wait until it knows the right data.
>>>>>>It's not an easy problem. If we get a 301, then we should definitely
rewrite the working copy to use the new URL. But... is a 301 correct, if "old" revisions still
work? ....
>>>>>>Cheers,
>>>>>>-g
>>>>>>On Feb 3, 2013 2:33 PM, "Joe Schaefer" <joe_schaefer@yahoo.com>
wrote:
>>>>>>
>>>>>>We don't actually need the subversion server
>>>>>>>to do anything useful with the query string
>>>>>>>on an OPTIONS request.  We just need it as
>>>>>>>a hint for http server admins, combined with
>>>>>>>a (global) configuration option to tell our
>>>>>>>working copies to autoswitch when they see a
>>>>>>>301 on the initial OPTIONS response.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Sorry if this is getting boring.  In no way is
>>>>>>>it essential, but we have significant working copy
>>>>>>>investments in incubating projects that are a pain
>>>>>>>to manage administratively right now whenever a project
>>>>>>>graduates.  Anything along these lines to cut down
>>>>>>>on the human labor aspects would be most welcome.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>________________________________
>>>>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>>>>To: Greg Stein <gstein@gmail.com> 
>>>>>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>

>>>>>>>>Sent: Sunday, February 3, 2013 1:45 PM
>>>>>>>>Subject: Re: Coniguring 301/302 redirects to track an fspath
rename
>>>>>>>> 
>>>>>>>>
>>>>>>>>IOW the easiest way for us to support OPTIONS
>>>>>>>>requests with this module, which would require
>>>>>>>>no code changes to the module I wrote, is for the
>>>>>>>>initial OPTIONS request to hang a ?p=whatever
>>>>>>>>query string onto the request whenever it's dealing
>>>>>>>>with pegrevs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>________________________________
>>>>>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>>>>>To: Greg Stein <gstein@gmail.com> 
>>>>>>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>

>>>>>>>>>Sent: Sunday, February 3, 2013 1:04 PM
>>>>>>>>>Subject: Re: Coniguring 301/302 redirects to track an
fspath rename
>>>>>>>>> 
>>>>>>>>>
>>>>>>>>>A few urls to fetch to get the basic idea:
>>>>>>>>>
>>>>>>>>>http://svn.apache.org/repos/asf/incubator/openmeetings/trunk
>>>>>>>>>(will redirect)
>>>>>>>>>
>>>>>>>>>http://svn.apache.org/repos/asf/incubator/openmeetings/trunk?p=1400000
>>>>>>>>>(won't redirect)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>________________________________
>>>>>>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>>>>>>To: Greg Stein <gstein@gmail.com> 
>>>>>>>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>

>>>>>>>>>>Sent: Sunday, February 3, 2013 12:15 PM
>>>>>>>>>>Subject: Re: Coniguring 301/302 redirects to track
an fspath rename
>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>>The code is here if you are interested (dunno
>>>>>>>>>>if it's publicly accessible or not but I believe
>>>>>>>>>>so).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>________________________________
>>>>>>>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>>>>>>>To: Greg Stein <gstein@gmail.com> 
>>>>>>>>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>

>>>>>>>>>>>Sent: Sunday, February 3, 2013 12:10 PM
>>>>>>>>>>>Subject: Re: Coniguring 301/302 redirects to track
an fspath rename
>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>>I backed off with the idea of trying to coax
>>>>>>>>>>>new behavior out of svn clients by munging OPTIONS
>>>>>>>>>>>responses, but GET and HEAD are now doing
>>>>>>>>>>>interesting things even with ?p= set.  For our
>>>>>>>>>>>purposes someday it would be nice to just have
>>>>>>>>>>>a graduating podling's checkouts all auto-switch
>>>>>>>>>>>to the moved location.  Whether that's
>>>>>>>>>>>accomplished by augmenting an OPTIONS request
>>>>>>>>>>>with revision details or just using the existing
>>>>>>>>>>>GET/HEAD support or some other method would be
>>>>>>>>>>>just fine with me.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>________________________________
>>>>>>>>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>>>>>>>>To: Greg Stein <gstein@gmail.com> 
>>>>>>>>>>>>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>

>>>>>>>>>>>>Sent: Saturday, February 2, 2013 2:07 AM
>>>>>>>>>>>>Subject: Re: Coniguring 301/302 redirects
to track an fspath rename
>>>>>>>>>>>> 
>>>>>>>>>>>>
>>>>>>>>>>>>The (pegrev) revision is typically available
on
>>>>>>>>>>>>the command-line: all I want is for svn to
distinguish
>>>>>>>>>>>>between
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    svn ls foo@1000000
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    svn ls foo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>as far as making redirects pegrev-aware.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>________________________________
>>>>>>>>>>>>> From: Greg Stein <gstein@gmail.com>
>>>>>>>>>>>>>To: Joe Schaefer <joe_schaefer@yahoo.com>

>>>>>>>>>>>>>Cc: dev@subversion.apache.org 
>>>>>>>>>>>>>Sent: Saturday, February 2, 2013 1:53
AM
>>>>>>>>>>>>>Subject: Re: Coniguring 301/302 redirects
to track an fspath rename
>>>>>>>>>>>>> 
>>>>>>>>>>>>>
>>>>>>>>>>>>>Oh, and to the second part: the code which
sends OPTIONS has no knowledge about the future operations. There is no way to send <revision/>,
or similar. *Very* disconnected, as in: not even cheesy-hackable.
>>>>>>>>>>>>>Cheers,
>>>>>>>>>>>>>-g
>>>>>>>>>>>>>On Feb 2, 2013 1:49 AM, "Greg Stein" <gstein@gmail.com>
wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>That OPTIONS request is generic, and contains
no information about the future operation(s) that will be performed on the connection. It
is used for the client to validate and gather information about the server.
>>>>>>>>>>>>>>Cheers,
>>>>>>>>>>>>>>-g
>>>>>>>>>>>>>>On Feb 2, 2013 1:23 AM, "Joe Schaefer"
<joe_schaefer@yahoo.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>So I now see the request body (xml
payload)
>>>>>>>>>>>>>>>in the OPTIONS request, but nothing
there nor
>>>>>>>>>>>>>>>in the headers tells me about
revision numbers.
>>>>>>>>>>>>>>>If I can convince you to add a
<revision/> block
>>>>>>>>>>>>>>>to the OPTIONS request body I
can handle the rest
>>>>>>>>>>>>>>>from the httpd side.  Obviously
this won't help
>>>>>>>>>>>>>>>existing clients, but hey it's
a gee-whiz feature
>>>>>>>>>>>>>>>anyhow.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>________________________________
>>>>>>>>>>>>>>>> From: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>>>>>>>>>>>>>To: 'Daniel Shahaf' <d.s@daniel.shahaf.name>;
Bert Huijben <bert@qqmail.nl> 
>>>>>>>>>>>>>>>>Cc: "dev@subversion.apache.org"
<dev@subversion.apache.org> 
>>>>>>>>>>>>>>>>Sent: Friday, February 1,
2013 9:26 PM
>>>>>>>>>>>>>>>>Subject: Re: Coniguring 301/302
redirects to track an fspath rename
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>So I have this implemented
about as well
>>>>>>>>>>>>>>>>as I can with what I know
about OPTIONS
>>>>>>>>>>>>>>>>requests that svn generates. 
It would
>>>>>>>>>>>>>>>>help if I knew how svn supplies
revision
>>>>>>>>>>>>>>>>information in the OPTIONS
request headers
>>>>>>>>>>>>>>>>so I can pass that along to
the codebase
>>>>>>>>>>>>>>>>instead of always using the
youngest rev.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>________________________________
>>>>>>>>>>>>>>>>> From: 'Daniel Shahaf'
<d.s@daniel.shahaf.name>
>>>>>>>>>>>>>>>>>To: Bert Huijben <bert@qqmail.nl>

>>>>>>>>>>>>>>>>>Cc: dev@subversion.apache.org

>>>>>>>>>>>>>>>>>Sent: Friday, February
1, 2013 3:33 PM
>>>>>>>>>>>>>>>>>Subject: Re: Coniguring
301/302 redirects to track an fspath rename
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>Bert Huijben wrote on
Fri, Feb 01, 2013 at 21:28:10 +0100:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> > -----Original
Message-----
>>>>>>>>>>>>>>>>>> > From: Daniel
Shahaf [mailto:d.s@daniel.shahaf.name]
>>>>>>>>>>>>>>>>>> > Sent: vrijdag
1 februari 2013 19:11
>>>>>>>>>>>>>>>>>> > To: dev@subversion.apache.org
>>>>>>>>>>>>>>>>>> > Subject: Coniguring
301/302 redirects to track an fspath rename
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > Does anyone
have an example of how to configure a server to issue
>>>>>>>>>>>>>>>>>> > 301/302 redirects
for an fspath that had been renamed?
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > For example
we have
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> >     <Location
/repos/asf>
>>>>>>>>>>>>>>>>>> >     SVNPath
...
>>>>>>>>>>>>>>>>>> >     </Location>
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > And we'd like
to do:
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > 
    # The project was renamed
>>>>>>>>>>>>>>>>>> >     Redirect
/repos/asf/openejb https://svn.apache.org/repos/asf/tomee
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > but we're hitting
various problems:
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > - The redirect
kicks in for historical revisions (prior to the 'svn mv
>>>>>>>>>>>>>>>>>> >   ^/openejb
^/tomee' in r1432805) too, such as:
>>>>>>>>>>>>>>>>>> >  https://svn.apache.org/repos/asf/openejb?p=1400000
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > - A similar
configuration failed to kick in during update/checkout of
>>>>>>>>>>>>>>>>>> >   working copy
checked out from (a pre-rename revision of) ^/openejb:
>>>>>>>>>>>>>>>>>> >   the initial
request got matched and redirected, but a subsequent
>>>>>>>>>>>>>>>>>> >   request to
/repos/asf/!svn/.../openejb failed to match.
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > Ideally we'd
like
 to issue a 301 redirect for requests to /openejb that
>>>>>>>>>>>>>>>>>> > concern r1432805
or later, but leave requests concerning r1432804 or
>>>>>>>>>>>>>>>>>> > earlier untouched.
>>>>>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>>>>>> > (or maybe what
we *really* want is a repos-side symlink... but we're
>>>>>>>>>>>>>>>>>> > running 1.7,
not 1.9, and we'll appreciate solutions that work within
>>>>>>>>>>>>>>>>>> > that limitation
:))
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> We currently only
support redirects above the repository level.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Redirections inside
would be a completely different feature.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>OK... :(
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why not just leave
a top level folder with some readme?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Every time a podling graduates
from the incubator, we do a rename:
>>>>>>>>>>>>>>>>>   svn mv ^/incubator/flex
^/flex
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>If we can return 301 whenever
somebody does 'svn up' in a wc of
>>>>>>>>>>>>>>>>>^/incubator/flex, we'll
save many users (2-4 projects every month)
>>>>>>>>>>>>>>>>>having to learn about
'svn relocate'.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think you
 should be able to redirect the normal webbrowser GETs though, as
>>>>>>>>>>>>>>>>>> I don't think we
use those urls from our ra layers. (Or did we start using
>>>>>>>>>>>>>>>>>> them for HEAD requests
in HTTPv2?)
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>'svn ls $URL@peg' was
affected by the redirects I had.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     Bert
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Daniel
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Mime
View raw message