On Tue, Feb 19, 2019 at 9:10 PM Jonathan Tan wrote:
>
> > > Good points about SSH support and the client needing to control which
> > > protocols the server will send URIs for. I'll include a line in the
> > > client request in which the client can specify which protocols it is OK
> > > with.
> >
On Thu, Feb 21 2019, brian m. carlson wrote:
> On Tue, Feb 19, 2019 at 02:44:31PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Tue, Dec 04 2018, brian m. carlson wrote:
>> > First, I'd like to see a section (and a bit in the implementation)
>> > requiring HTTPS if the original protocol is secu
On Tue, Feb 19, 2019 at 02:44:31PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Dec 04 2018, brian m. carlson wrote:
> > 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 downgra
> > +when the server sends the packfile, it MAY send a `packfile-uris` section
> > +directly before the `packfile` section (right after `wanted-refs` if it is
> > +sent) containing HTTP(S) URIs. See protocol-v2.txt for the documentation of
> > +this section.
> > +
> > +Clients then should understan
> > Good points about SSH support and the client needing to control which
> > protocols the server will send URIs for. I'll include a line in the
> > client request in which the client can specify which protocols it is OK
> > with.
>
> What if a client is ok to fetch from some servers but not othe
On Tue, Dec 04 2018, Jonathan Tan wrote:
I meant to follow-up after Git Merge, but didn't remember until this
thread was bumped.
But some things I'd like to clarify / am concerned about...
> +when the server sends the packfile, it MAY send a `packfile-uris` section
> +directly before the `pack
On Tue, Dec 04 2018, brian m. carlson wrote:
> 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,
On Tue, Dec 4, 2018 at 8:31 PM Jonathan Tan wrote:
>
> > 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
> > +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 resumabilit
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 pa
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 resum
> 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
14 matches
Mail list logo
