You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Hammant <pa...@hammant.org> on 2018/04/15 12:52:52 UTC
Subversion clients following HTTP 302 response codes.
It would be cool if svn.exe (the client) could follow HTTP return code '302'
during svn-co and svn-up operations.
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 select 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
I'd go ahead a raise a Jira feature request, depending on the outcome of
this debate, per dev-team rules.
Thoughts?
- Paul
Re: Subversion clients following HTTP 302 response codes.
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 19:49, Paul Hammant wrote:
>
> I'm still wondering what you're aiming for though. An obvious example
> would be offloading resource content storage from the repository
> server
> to some other storage. But if you want to do that, relying on
> redirects
> is hardly a good option, since you'd be increasing the number of
> requests and hence the latency. Transparent load balancing on the
> server
> side is probably a much better solution.
>
>
>
> Overall system throughput is what I'm aiming at - large payloads for
> thousands of users concurrently (and spread worldwide) are a focus for
> me - remember the timing info I was positing (sometime inaccurately I
> grant you) some months ago. Latency increasing (before a single GET
> starts streaming) isn't a worry for me.
Most of the time, what a Subversion client GETs from the server is a
delta from what it already has in the working copy to what the server
contains in its repository. That makes caching or CDN-like distribution
for those resources a tricky proposition, since every working copy is
potentially different.
Can you show some examples or perhaps measurements where such content
distribution would actually give a tangible benefit in actual use? The
only cases I can think of is when you use the repository with something
other than the Subversion client, or intentionally always without a
working copy.
-- Brane
Re: Subversion clients following HTTP 302 response codes.
Posted by Branko Čibej <br...@apache.org>.
On 26.04.2018 11:47, Paul Hammant wrote:
> Re https://issues.apache.org/jira/browse/SVN-4738
> <https://issues.apache.org/jira/browse/SVN-4738>
>
> If I paid for this to be developed (say on UpWork), what criteria
> would that work have to meet to be consumed into Subversion's trunk
> for later release? I ask because I'd not want to pay for its
> development then have it rejected for a long list of reasons. I'd
> rather bake those into the acceptance criteria.
As with any contribution to any Apache project, "discuss design and
intended changes on the dev@ list" is a pretty basic requirement. I'd
suggest you start with that before issuing any work orders. Filing an
issue in Jira isn't the same as discussing the proposed change. There
has been very little discussion of your proposal on this list, and we're
nowhere near a consensus.
> As part of the paid development work I'd get copyright assigned to me
> by the contractor, and being an Apache member with a CLA on file from
> 2002 or so, I'd then grant copyright to Apache for the work.
Ah ... I don't think so? Contributors to Apache projects are
individuals, not companies (IMO, for the purpose of this discussion,
you'd count as "company" if you hired someone else do do the actual
work). If the scope of the work is large enough, the author must file an
ICLA. You don't get to stand in as a proxy.
-- Brane
Re: Subversion clients following HTTP 302 response codes.
Posted by Paul Hammant <pa...@hammant.org>.
Re https://issues.apache.org/jira/browse/SVN-4738
If I paid for this to be developed (say on UpWork), what criteria would
that work have to meet to be consumed into Subversion's trunk for later
release? I ask because I'd not want to pay for its development then have
it rejected for a long list of reasons. I'd rather bake those into the
acceptance criteria. As part of the paid development work I'd get
copyright assigned to me by the contractor, and being an Apache member with
a CLA on file from 2002 or so, I'd then grant copyright to Apache for the
work.
Regards,
- Paul
Re: Subversion clients following HTTP 302 response codes.
Posted by Paul Hammant <pa...@hammant.org>.
My bad - I pasted/typed into the env field rather than the desc one. Fixed.
Re: Subversion clients following HTTP 302 response codes.
Posted by Branko Čibej <br...@apache.org>.
On 17.04.2018 17:22, Paul Hammant wrote:
> https://issues.apache.org/jira/browse/SVN-4738 filed :)
Hmmm ... the environment described in that feature is interesting.
-- Brane
P.S.: Yes, I've often though that the Jira issue creation UI is broken
in this respect.
Re: Subversion clients following HTTP 302 response codes.
Posted by Paul Hammant <pa...@hammant.org>.
https://issues.apache.org/jira/browse/SVN-4738 filed :)
Re: Subversion clients following HTTP 302 response codes.
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 19:49, Paul Hammant wrote:
>
> I'm still wondering what you're aiming for though. An obvious example
> would be offloading resource content storage from the repository
> server
> to some other storage. But if you want to do that, relying on
> redirects
> is hardly a good option, since you'd be increasing the number of
> requests and hence the latency. Transparent load balancing on the
> server
> side is probably a much better solution.
>
>
>
> Overall system throughput is what I'm aiming at - large payloads for
> thousands of users concurrently (and spread worldwide) are a focus for
> me - remember the timing info I was positing (sometime inaccurately I
> grant you) some months ago. Latency increasing (before a single GET
> starts streaming) isn't a worry for me.
>
>
>
> Other than that consideration, I don't see any technical barrier to
> supporting redirects within a live session ... the DAV/HTTPv2 experts
> should chime in here.
>
>
> I think DAV's enhancements to HTTP came for v1.1 not 2.0.
"HTTPv2" in this context is Subversion's second-generation HTTP-based
client/server protocol. :)
Re: Subversion clients following HTTP 302 response codes.
Posted by Paul Hammant <pa...@hammant.org>.
> I'm still wondering what you're aiming for though. An obvious example
> would be offloading resource content storage from the repository server
> to some other storage. But if you want to do that, relying on redirects
> is hardly a good option, since you'd be increasing the number of
> requests and hence the latency. Transparent load balancing on the server
> side is probably a much better solution.
>
Overall system throughput is what I'm aiming at - large payloads for
thousands of users concurrently (and spread worldwide) are a focus for me -
remember the timing info I was positing (sometime inaccurately I grant you)
some months ago. Latency increasing (before a single GET starts streaming)
isn't a worry for me.
>
> Other than that consideration, I don't see any technical barrier to
> supporting redirects within a live session ... the DAV/HTTPv2 experts
> should chime in here.
>
I think DAV's enhancements to HTTP came for v1.1 not 2.0.
- Paul
Re: Subversion clients following HTTP 302 response codes.
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 15:20, Paul Hammant wrote:
> The main conversation - PROPFIND, OPTIONS etc with a canonical
> centralized server, _but_ select GETs (among many) being redirected to
> other URLs.
>
> My testing didn't show that that was supported. As a good XPer, I
> should be able to conjure up a script to show that but I can't, so I
> mean manual testing for now.
That's true, redirects are followed only during RA session creation, so
that's during the initial handshake with the server. All requests within
the session then use the resolved URL and expect the repository not to
move elsewhere.
I'm still wondering what you're aiming for though. An obvious example
would be offloading resource content storage from the repository server
to some other storage. But if you want to do that, relying on redirects
is hardly a good option, since you'd be increasing the number of
requests and hence the latency. Transparent load balancing on the server
side is probably a much better solution.
Other than that consideration, I don't see any technical barrier to
supporting redirects within a live session ... the DAV/HTTPv2 experts
should chime in here.
-- Brane
Re: Subversion clients following HTTP 302 response codes.
Posted by Paul Hammant <pa...@hammant.org>.
The main conversation - PROPFIND, OPTIONS etc with a canonical centralized
server, *but* select GETs (among many) being redirected to other URLs.
My testing didn't show that that was supported. As a good XPer, I should be
able to conjure up a script to show that but I can't, so I mean manual
testing for now.
Re: Subversion clients following HTTP 302 response codes.
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 14:52, Paul Hammant wrote:
> It would be cool if svn.exe (the client) could follow HTTP return code
> '302' during svn-co and svn-up operations.
>
> 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 select 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
>
> I'd go ahead a raise a Jira feature request, depending on the outcome
> of this debate, per dev-team rules.
>
> Thoughts?
The Subversion client already handles redirects when initiating HTTP(S)
connections to the server. So I'm not sure what else you'd want it to do.
-- Brane