subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Hammant (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SVN-4738) Subversion clients following HTTP 302 response codes.
Date Tue, 17 Apr 2018 15:56:00 GMT

     [ 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)

Mime
View raw message