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_schae...@yahoo.com> >To: Greg Stein <gst...@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_schae...@yahoo.com> >>To: Greg Stein <gst...@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 <gst...@gmail.com> >>>To: Joe Schaefer <joe_schae...@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_schae...@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_schae...@yahoo.com> >>>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>>>>To: Greg Stein <gst...@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_schae...@yahoo.com> >>>>>>>>>To: Greg Stein <gst...@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 <gst...@gmail.com> >>>>>>>>>>To: Joe Schaefer <joe_schae...@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" <gst...@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_schae...@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_schae...@yahoo.com> >>>>>>>>>>>>>To: 'Daniel Shahaf' <d...@daniel.shahaf.name>; Bert Huijben >>>>>>>>>>>>><b...@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...@daniel.shahaf.name> >>>>>>>>>>>>>>To: Bert Huijben <b...@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...@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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >> >> > >
