> > +This feature allows servers to serve part of their packfile response as
> > URIs.
> > +This allows server designs that improve scalability in bandwidth and CPU
> > usage
> > +(for example, by serving some data through a CDN), and (in the future)
> > provides
> > +some measure of
Junio C Hamano writes:
> So, this is OK, but
>
>> +Clients then should understand that the returned packfile could be
>> incomplete,
>> +and that it needs to download all the given URIs before the fetch or clone
>> is
>> +complete. Each URI should point to a Git packfile (which may be a thin
Jonathan Tan writes:
> +This feature allows servers to serve part of their packfile response as URIs.
> +This allows server designs that improve scalability in bandwidth and CPU
> usage
> +(for example, by serving some data through a CDN), and (in the future)
> provides
> +some measure of
> Some thoughts here:
>
> First, I'd like to see a section (and a bit in the implementation)
> requiring HTTPS if the original protocol is secure (SSH or HTTPS).
> Allowing the server to downgrade to HTTP, even by accident, would be a
> security problem.
>
> Second, this feature likely should be
On Mon, Dec 03, 2018 at 03:37:35PM -0800, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> Documentation/technical/packfile-uri.txt | 83
> Documentation/technical/protocol-v2.txt | 6 +-
> 2 files changed, 88 insertions(+), 1 deletion(-)
> create mode 100644
Thanks for bringing this design to the list!
> diff --git a/Documentation/technical/protocol-v2.txt
> b/Documentation/technical/protocol-v2.txt
> index 345c00e08c..2cb1c41742 100644
> --- a/Documentation/technical/protocol-v2.txt
> +++ b/Documentation/technical/protocol-v2.txt
> @@ -313,7 +313,8
6 matches
Mail list logo
