Details
-
New Feature
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
It would be cool if svn.exe (the client) could follow HTTP return code '302' during svn-co and svn-up operations. Possibly also, language bindings and a spec update in documentation.
I'm thinking that this is just for GET* of resources, and that someone who's managed to front their Mod_Dav_Svn with something that can do redirects for selected resources. Say to resources in S3.
(request)
GET /repos/asf/!svn/rvr/1234/path/to/movie.mp4 HTTP/1.1
Host: svn.example.com
User-Agent: SVN/1.9.7 (x86_64-apple-darwin17.3.0) serf/1.3.9
Accept-Encoding: gzip
(response)
302 Found
Location: https://foobar.s3.amazonaws.com/1234/path/to/movie.mp4
(subsequent request)
GET 1234/path/to/movie.mp4 HTTP/1.1
Host: foobar.s3.amazonaws.com
User-Agent: SVN/1.9.7 (x86_64-apple-darwin17.3.0) serf/1.3.9
Accept-Encoding: gzip
(Amazon itself does more 302's here, probably)
You could make a general case that any (or more than just GET) of the HTTP methods could be redirectable but discussing GET is a narrow case for the sake of a debate.
Also, you could make a case for 307 responses too - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
Rationale: Overall system throughput is what I'm aiming at - large payloads for thousands of users concurrently (and spread worldwide) are a focus area for me. Latency increasing (for each redirected GET start to stream) isn't a worry for me.
Note: The Subversion client already handles redirects when initiating HTTP(S), but this is for following GET operations after the initial connect.
Note2: Redirects to other sub-domains would assume that the same Basic Auth (if supplied via --username and --password), whereas redirects to other domains would not use the same Basic Auth (if supplied via --username and --password) and prompt again or pull from those available in ~/.subversion/