<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/methods/server.h, branch 1.3.1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3.1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3.1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-08-16T16:49:37Z</updated>
<entry>
<title>don't sent Range requests if we know its not accepted</title>
<updated>2016-08-16T16:49:37Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-11T16:24:35Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d94b1d80d8326334d17f6a43061368e783b8e0aa'/>
<id>urn:sha1:d94b1d80d8326334d17f6a43061368e783b8e0aa</id>
<content type='text'>
If the server told us in a previous request that it isn't supporting
Ranges with bytes via an Accept-Ranges header missing bytes, we don't
try to formulate requests using Ranges.
</content>
</entry>
<entry>
<title>reorganize server-states resetting in http/https</title>
<updated>2016-08-16T16:49:37Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-11T14:59:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ebdb6f1810a20ac240b5b2192dc2e6532ff149d2'/>
<id>urn:sha1:ebdb6f1810a20ac240b5b2192dc2e6532ff149d2</id>
<content type='text'>
We keep various information bits about the server around, some only
effecting the currently handled file (like sizes) while others
should be persistent (like pipeline detections). http used to reset all
file-related manually, which is a bit silly if we already have a Reset()
method – which does reset all through –, so extending it with a
parameter for reuse and calling it from https too (as this was
previously resetting by just creating a new state struct – it uses no
value of the persistent state-keeping yet as it supports no pipelining).

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>http: auto-configure for local Tor proxy if called as 'tor'</title>
<updated>2016-08-10T23:34:39Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-06T20:54:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0568d325ad8660a9966d552634aa17c90ed22516'/>
<id>urn:sha1:0568d325ad8660a9966d552634aa17c90ed22516</id>
<content type='text'>
With apts http transport supporting socks5h proxies and all the work
in terms of configuration of methods based on the name it is called with
it becomes surprisingly easy to implement Tor support equally (and
perhaps even a bit exceeding) what is available currently in
apt-transport-tor.

How this will turn out to be handled packaging wise we will see in
https://lists.debian.org/deity/2016/08/msg00012.html , but until this is
resolved we can add the needed support without actively enabling it for
now, so that this can be tested better.
</content>
</entry>
<entry>
<title>implement generic config fallback for methods</title>
<updated>2016-08-10T21:19:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-31T16:05:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=30060442025824c491f58887ca7369f3c572fa57'/>
<id>urn:sha1:30060442025824c491f58887ca7369f3c572fa57</id>
<content type='text'>
The https method implemented for a long while now a hardcoded fallback
to the same options in http, which, while it works, is rather inflexible
if we want to allow the methods to use another name to change their
behavior slightly, like apt-transport-tor does to https – most of the
diff being s#https#tor#g which then fails to do the full circle
fallthrough tor -&gt; https -&gt; http for https sources. With this config
infrastructure this could be implemented now.
</content>
</entry>
<entry>
<title>use the same redirection handling for http and https</title>
<updated>2016-08-10T21:19:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-02T12:49:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4bba5a88d0f6afde4414b586b64c48a4851d5324'/>
<id>urn:sha1:4bba5a88d0f6afde4414b586b64c48a4851d5324</id>
<content type='text'>
cURL which backs our https implementation can handle redirects on its
own, but by dealing with them on our own we gain finer control over which
redirections will be performed (we don't like https → http) and by whom
so that redirections to other hosts correctly spawn a new https method
dealing with these instead of letting the current one deal with it.
</content>
</entry>
<entry>
<title>detect redirection loops in acquire instead of workers</title>
<updated>2016-08-10T21:19:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-02T20:44:50Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=57401c48fadc0c78733a67294f9cc20a57e527c9'/>
<id>urn:sha1:57401c48fadc0c78733a67294f9cc20a57e527c9</id>
<content type='text'>
Having the detection handled in specific (http) workers means that a
redirection loop over different hostnames isn't detected. Its also not a
good idea have this implement in each method independently even if it
would work
</content>
</entry>
<entry>
<title>avoid 416 response teardown binding to null pointer</title>
<updated>2016-07-05T18:44:45Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-05T11:07:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4460551841d909d3ee9c1de00156ed3cdf8b1665'/>
<id>urn:sha1:4460551841d909d3ee9c1de00156ed3cdf8b1665</id>
<content type='text'>
methods/http.cc:640:13: runtime error: reference binding to null pointer
of type 'struct FileFd'

This reference is never used in the cases it has a nullptr, so the
practical difference is non-existent, but its a bug still.

Reported-By: gcc -fsanitize=undefined
</content>
</entry>
<entry>
<title>use std::locale::global instead of setlocale</title>
<updated>2016-05-28T16:12:02Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-28T11:22:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8b79c94af7f7cf2e5e5342294bc6e5a908cacabf'/>
<id>urn:sha1:8b79c94af7f7cf2e5e5342294bc6e5a908cacabf</id>
<content type='text'>
We use a wild mixture of C and C++ ways of generating output, so having
a consistent world-view in both styles sounds like a good idea and
should help in preventing regressions.
</content>
</entry>
<entry>
<title>Only enable pipelining if server is HTTP/1.1</title>
<updated>2016-01-12T22:40:59Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-01-12T14:18:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b6d88f39aceda2e093e1bf8751f07236b7d9e483'/>
<id>urn:sha1:b6d88f39aceda2e093e1bf8751f07236b7d9e483</id>
<content type='text'>
Just enabling it for anyone breaks with HTTP/1.0 servers and
proxies sometimes.

Closes: #810796
</content>
</entry>
<entry>
<title>allow acquire method specific options via Binary scope</title>
<updated>2015-11-05T11:21:33Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-04T13:48:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=23e64f6d0facf9610c1042326ad9850e071e8349'/>
<id>urn:sha1:23e64f6d0facf9610c1042326ad9850e071e8349</id>
<content type='text'>
Allows users who know what they are getting themselves into with this
trick to e.g. disable privilege dropping for e.g. file:// until they can
fix up the permissions on those repositories. It helps also the test
framework and people with a similar setup (= me) to run in less modified
environments.
</content>
</entry>
</feed>
