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
Received on 2010-07-30 09:56:03 CEST