<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/libgit2.git/src/transports/http.h, branch ethomson/test_https</title>
<subtitle>github.com: libgit2/libgit2.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/'/>
<entry>
<title>str: introduce `git_str` for internal, `git_buf` is external</title>
<updated>2021-10-17T13:49:01+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2021-09-07T21:53:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=f0e693b18afbe1de37d7da5b5a8967b6c87d8e53'/>
<id>f0e693b18afbe1de37d7da5b5a8967b6c87d8e53</id>
<content type='text'>
libgit2 has two distinct requirements that were previously solved by
`git_buf`.  We require:

1. A general purpose string class that provides a number of utility APIs
   for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
   can take ownership of.

By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.

Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class.  The name also
is an homage to Junio Hamano ("gitstr").

The public API remains `git_buf`, and has a much smaller footprint.  It
is generally only used as an "out" param with strict requirements that
follow the documentation.  (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)

Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
libgit2 has two distinct requirements that were previously solved by
`git_buf`.  We require:

1. A general purpose string class that provides a number of utility APIs
   for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
   can take ownership of.

By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.

Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class.  The name also
is an homage to Junio Hamano ("gitstr").

The public API remains `git_buf`, and has a much smaller footprint.  It
is generally only used as an "out" param with strict requirements that
follow the documentation.  (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)

Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
</pre>
</div>
</content>
</entry>
<entry>
<title>settings: localize global data</title>
<updated>2020-10-11T13:43:35+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-05-13T09:39:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=6554b40e42df831d7fc9c623d34b2738227dd8a2'/>
<id>6554b40e42df831d7fc9c623d34b2738227dd8a2</id>
<content type='text'>
Move the settings global data teardown into its own separate function,
instead of intermingled with the global state.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move the settings global data teardown into its own separate function,
instead of intermingled with the global state.
</pre>
</div>
</content>
</entry>
<entry>
<title>http: use the new httpclient</title>
<updated>2020-01-24T16:39:51+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2019-12-22T22:12:24+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=b9c5b15a7958ab4ecb83504a6d858efd18610297'/>
<id>b9c5b15a7958ab4ecb83504a6d858efd18610297</id>
<content type='text'>
Untangle the notion of the http transport from the actual http
implementation.  The http transport now uses the httpclient.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Untangle the notion of the http transport from the actual http
implementation.  The http transport now uses the httpclient.
</pre>
</div>
</content>
</entry>
<entry>
<title>httpclient: support expect/continue</title>
<updated>2020-01-24T16:16:36+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2019-10-25T11:22:10+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=7372573b5f1113b8522e2588fac1c529ddcedb0a'/>
<id>7372573b5f1113b8522e2588fac1c529ddcedb0a</id>
<content type='text'>
Allow users to opt-in to expect/continue handling when sending a POST
and we're authenticated with a "connection-based" authentication
mechanism like NTLM or Negotiate.

If the response is a 100, return to the caller (to allow them to post
their body).  If the response is *not* a 100, buffer the response for
the caller.

HTTP expect/continue is generally safe, but some legacy servers
have not implemented it correctly.  Require it to be opt-in.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allow users to opt-in to expect/continue handling when sending a POST
and we're authenticated with a "connection-based" authentication
mechanism like NTLM or Negotiate.

If the response is a 100, return to the caller (to allow them to post
their body).  If the response is *not* a 100, buffer the response for
the caller.

HTTP expect/continue is generally safe, but some legacy servers
have not implemented it correctly.  Require it to be opt-in.
</pre>
</div>
</content>
</entry>
<entry>
<title>http: increase the replay count</title>
<updated>2019-06-10T18:58:22+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2019-03-14T10:36:40+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=956ba48bdd488d4e22dd5a468df952765b8c9824'/>
<id>956ba48bdd488d4e22dd5a468df952765b8c9824</id>
<content type='text'>
Increase the permissible replay count; with multiple-step authentication
schemes (NTLM, Negotiate), proxy authentication and redirects, we need
to be mindful of the number of steps it takes to get connected.

7 seems high but can be exhausted quickly with just a single authentication
failure over a redirected multi-state authentication pipeline.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Increase the permissible replay count; with multiple-step authentication
schemes (NTLM, Negotiate), proxy authentication and redirects, we need
to be mindful of the number of steps it takes to get connected.

7 seems high but can be exhausted quickly with just a single authentication
failure over a redirected multi-state authentication pipeline.
</pre>
</div>
</content>
</entry>
<entry>
<title>http transport: cap number of authentication replays</title>
<updated>2018-11-28T15:30:17+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2018-10-22T10:29:01+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=6af8572c7f282f458c6c63b005a85c46a14569db'/>
<id>6af8572c7f282f458c6c63b005a85c46a14569db</id>
<content type='text'>
Put a limit on the number of authentication replays in the HTTP
transport.  Standardize on 7 replays for authentication or redirects,
which matches the behavior of the WinHTTP transport.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Put a limit on the number of authentication replays in the HTTP
transport.  Standardize on 7 replays for authentication or redirects,
which matches the behavior of the WinHTTP transport.
</pre>
</div>
</content>
</entry>
<entry>
<title>http: standardize user-agent addition</title>
<updated>2018-02-10T07:05:55+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2018-01-31T16:36:19+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=ee6be190e69ae26cec589e99b48f901b18b8e873'/>
<id>ee6be190e69ae26cec589e99b48f901b18b8e873</id>
<content type='text'>
The winhttp and posix http each need to add the user-agent to their
requests.  Standardize on a single function to include this so that we
do not get the version numbers we're sending out of sync.

Assemble the complete user agent in `git_http__user_agent`, returning
assembled strings.

Co-authored-by: Patrick Steinhardt &lt;ps@pks.im&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The winhttp and posix http each need to add the user-agent to their
requests.  Standardize on a single function to include this so that we
do not get the version numbers we're sending out of sync.

Assemble the complete user agent in `git_http__user_agent`, returning
assembled strings.

Co-authored-by: Patrick Steinhardt &lt;ps@pks.im&gt;
</pre>
</div>
</content>
</entry>
</feed>
