Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4738

Subversion clients following HTTP 302 response codes.



    • New Feature
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • cmdline client
    • None


      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.



      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
      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/




            Unassigned Unassigned
            paul Paul Hammant
            0 Vote for this issue
            1 Start watching this issue