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).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-07-30 03:21:58 CEST