On 30.07.2010 03:21, C. Michael Pilato wrote: > On 07/29/2010 08:54 PM, Mike Dixon wrote: > >> On 7/29/2010 9:43 AM, C. Michael Pilato wrote: >> >>> On 07/29/2010 12:28 PM, Mark Phippard wrote: >>> >>>> If we just do the redirects, might a user just not perceive SVN as >>>> being slow? >>>> >>> Well, the redirect should be a one-time event. The working copy is >>> updated >>> (using svn_client_relocate()) to point to the new, successfully contacted >>> URL. From then on, it's business as usually for the working copy. >>> It's not >>> like we're constantly following redirects because the working copy has >>> never >>> been relocated or anything. >>> >>> >> My apologies for jumping in here if I'm misunderstanding the issue, but >> the combination of "HTTP", "redirect" and "one-time event" pushed me out >> of passive list-reading mode. >> >> For a 301 redirect, sure, a relocate is appropriate. For other 3xx >> redirects, it may not be. I'm sure you've seen it, but: >> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 >> >> In particular, 302 and 307 are strictly temporary. There's also a note >> in 307 that redirection isn't allowed for anything other than GET or >> HEAD without prompting the user. >> >> It's up to you whether you think it's worth the effort or not, though. I >> mean, there's a lot of code out there that doesn't follow protocol >> exactly, and it sounds like always doing a relocate would at least be >> better than the current situation. I just wanted to make sure you didn't >> get to the end of your branch and go "oh hey, that's right, there are >> those other redirect codes...". >> > Mike, thanks for chiming in. I'm aware of the various redirect codes and > the permanent/temporary meanings they carry. Today, neither ra_serf nor > ra_neon recognizes the 307. 301 and 302 are distinguished by different > error messages (one says "permanently", one says "temporarily"). > > Technically speaking, we could try to distinguish between 301 and 302/307 by > allowing Subversion to communicate using the corrected URL while still > trying to persist the original URL in the working copy. Bug that's would be > so intrusive in the codebase as to be impractical at a minimum, with a > tendency towards just plain broken. > > Another approach (which has actually been requested of Subversion in the > past) would be for Subversion to squirrel away the requested URL in the > event of a 302/307 and remember it as a fallback URL. The request comes > from folks who want to implement load distribution or DR for their > Subversion services. Folks always checkout against a generic published URL, > but the server just redirects them to another specific server URL. If that > specific URL stops working (the machine goes down or whatever), Subversion > automatically retries against the squirreled-away original generic URL > (which perhaps now just redirects them to a different specific URL of a > machine that's *not* down). >
That approach just doesn't sound right to me. I've always understood that a temporary redirect implies that requests should always try the original first. Since there's no concept of a session in HTTP, you can't really assume anything about how long a redirect is valid -- it may be only for one single request and not for others. -- Brane
