[
https://issues.apache.org/jira/browse/SVN-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Hammant updated SVN-4738:
------------------------------
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.
{code:java}
(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)
{code}
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/
was:
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|http://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|http://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/
> Subversion clients following HTTP 302 response codes.
> -----------------------------------------------------
>
> Key: SVN-4738
> URL: https://issues.apache.org/jira/browse/SVN-4738
> Project: Subversion
> Issue Type: New Feature
> Components: cmdline client
> Reporter: Paul Hammant
> Priority: Minor
>
> 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.
>
>
> {code:java}
> (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)
> {code}
>
>
> 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/
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
