2005-11-19 03:02:58 +08:00
|
|
|
#ifndef HTTP_H
|
|
|
|
#define HTTP_H
|
|
|
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
|
|
|
#include <curl/curl.h>
|
|
|
|
#include <curl/easy.h>
|
|
|
|
|
2007-12-10 03:30:59 +08:00
|
|
|
#include "strbuf.h"
|
2008-02-28 04:35:50 +08:00
|
|
|
#include "remote.h"
|
2010-11-25 16:21:04 +08:00
|
|
|
#include "url.h"
|
2007-12-10 03:30:59 +08:00
|
|
|
|
2008-01-22 09:34:43 +08:00
|
|
|
/*
|
|
|
|
* We detect based on the cURL version if multi-transfer is
|
|
|
|
* usable in this implementation and define this symbol accordingly.
|
2014-04-01 06:11:46 +08:00
|
|
|
* This shouldn't be set by the Makefile or by the user (e.g. via CFLAGS).
|
2008-01-22 09:34:43 +08:00
|
|
|
*/
|
|
|
|
#undef USE_CURL_MULTI
|
|
|
|
|
2007-05-02 20:53:23 +08:00
|
|
|
#if LIBCURL_VERSION_NUM >= 0x071000
|
2005-11-19 03:02:58 +08:00
|
|
|
#define USE_CURL_MULTI
|
|
|
|
#define DEFAULT_MAX_REQUESTS 5
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if LIBCURL_VERSION_NUM < 0x070704
|
2010-08-13 06:11:15 +08:00
|
|
|
#define curl_global_cleanup() do { /* nothing */ } while (0)
|
2005-11-19 03:02:58 +08:00
|
|
|
#endif
|
|
|
|
#if LIBCURL_VERSION_NUM < 0x070800
|
2010-08-13 06:11:15 +08:00
|
|
|
#define curl_global_init(a) do { /* nothing */ } while (0)
|
2005-11-19 03:02:58 +08:00
|
|
|
#endif
|
|
|
|
|
2006-12-28 05:59:26 +08:00
|
|
|
#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)
|
2005-11-19 03:02:58 +08:00
|
|
|
#define NO_CURL_EASY_DUPHANDLE
|
|
|
|
#endif
|
|
|
|
|
2006-09-19 20:20:19 +08:00
|
|
|
#if LIBCURL_VERSION_NUM < 0x070a03
|
|
|
|
#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
|
|
|
|
#endif
|
|
|
|
|
2009-04-02 00:48:24 +08:00
|
|
|
#if LIBCURL_VERSION_NUM < 0x070c03
|
|
|
|
#define NO_CURL_IOCTL
|
|
|
|
#endif
|
|
|
|
|
2013-04-08 03:10:39 +08:00
|
|
|
/*
|
|
|
|
* CURLOPT_USE_SSL was known as CURLOPT_FTP_SSL up to 7.16.4,
|
|
|
|
* and the constants were known as CURLFTPSSL_*
|
|
|
|
*/
|
|
|
|
#if !defined(CURLOPT_USE_SSL) && defined(CURLOPT_FTP_SSL)
|
|
|
|
#define CURLOPT_USE_SSL CURLOPT_FTP_SSL
|
|
|
|
#define CURLUSESSL_TRY CURLFTPSSL_TRY
|
|
|
|
#endif
|
|
|
|
|
2011-03-16 15:08:34 +08:00
|
|
|
struct slot_results {
|
2006-02-01 03:06:55 +08:00
|
|
|
CURLcode curl_result;
|
|
|
|
long http_code;
|
2013-10-31 14:35:31 +08:00
|
|
|
long auth_avail;
|
http: use credential API to handle proxy authentication
Currently, the only way to pass proxy credentials to curl is by including them
in the proxy URL. Usually, this means they will end up on disk unencrypted, one
way or another (by inclusion in ~/.gitconfig, shell profile or history). Since
proxy authentication often uses a domain user, credentials can be security
sensitive; therefore, a safer way of passing credentials is desirable.
If the configured proxy contains a username but not a password, query the
credential API for one. Also, make sure we approve/reject proxy credentials
properly.
For consistency reasons, add parsing of http_proxy/https_proxy/all_proxy
environment variables, which would otherwise be evaluated as a fallback by curl.
Without this, we would have different semantics for git configuration and
environment variables.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 21:02:48 +08:00
|
|
|
long http_connectcode;
|
2006-02-01 03:06:55 +08:00
|
|
|
};
|
|
|
|
|
2011-03-16 15:08:34 +08:00
|
|
|
struct active_request_slot {
|
2005-11-19 03:02:58 +08:00
|
|
|
CURL *curl;
|
|
|
|
int in_use;
|
|
|
|
CURLcode curl_result;
|
|
|
|
long http_code;
|
2006-03-11 12:18:01 +08:00
|
|
|
int *finished;
|
2006-02-01 03:06:55 +08:00
|
|
|
struct slot_results *results;
|
2005-11-19 03:02:58 +08:00
|
|
|
void *callback_data;
|
|
|
|
void (*callback_func)(void *data);
|
|
|
|
struct active_request_slot *next;
|
|
|
|
};
|
|
|
|
|
2011-03-16 15:08:34 +08:00
|
|
|
struct buffer {
|
2007-12-10 03:30:59 +08:00
|
|
|
struct strbuf buf;
|
|
|
|
size_t posn;
|
2005-11-19 03:02:58 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Curl request read/write callbacks */
|
2011-05-03 23:47:27 +08:00
|
|
|
extern size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *strbuf);
|
|
|
|
extern size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void *strbuf);
|
|
|
|
extern size_t fwrite_null(char *ptr, size_t eltsize, size_t nmemb, void *strbuf);
|
2009-04-02 00:48:24 +08:00
|
|
|
#ifndef NO_CURL_IOCTL
|
|
|
|
extern curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp);
|
|
|
|
#endif
|
2005-11-19 03:02:58 +08:00
|
|
|
|
|
|
|
/* Slot lifecycle functions */
|
|
|
|
extern struct active_request_slot *get_active_slot(void);
|
|
|
|
extern int start_active_slot(struct active_request_slot *slot);
|
|
|
|
extern void run_active_slot(struct active_request_slot *slot);
|
|
|
|
extern void finish_all_active_slots(void);
|
|
|
|
|
http: never use curl_easy_perform
We currently don't reuse http connections when fetching via
the smart-http protocol. This is bad because the TCP
handshake introduces latency, and especially because SSL
connection setup may be non-trivial.
We can fix it by consistently using curl's "multi"
interface. The reason is rather complicated:
Our http code has two ways of being used: queuing many
"slots" to be fetched in parallel, or fetching a single
request in a blocking manner. The parallel code is built on
curl's "multi" interface. Most of the single-request code
uses http_request, which is built on top of the parallel
code (we just feed it one slot, and wait until it finishes).
However, one could also accomplish the single-request scheme
by avoiding curl's multi interface entirely and just using
curl_easy_perform. This is simpler, and is used by post_rpc
in the smart-http protocol.
It does work to use the same curl handle in both contexts,
as long as it is not at the same time. However, internally
curl may not share all of the cached resources between both
contexts. In particular, a connection formed using the
"multi" code will go into a reuse pool connected to the
"multi" object. Further requests using the "easy" interface
will not be able to reuse that connection.
The smart http protocol does ref discovery via http_request,
which uses the "multi" interface, and then follows up with
the "easy" interface for its rpc calls. As a result, we make
two HTTP connections rather than reusing a single one.
We could teach the ref discovery to use the "easy"
interface. But it is only once we have done this discovery
that we know whether the protocol will be smart or dumb. If
it is dumb, then our further requests, which want to fetch
objects in parallel, will not be able to reuse the same
connection.
Instead, this patch switches post_rpc to build on the
parallel interface, which means that we use it consistently
everywhere. It's a little more complicated to use, but since
we have the infrastructure already, it doesn't add any code;
we can just factor out the relevant bits from http_request.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-18 18:34:20 +08:00
|
|
|
/*
|
|
|
|
* This will run one slot to completion in a blocking manner, similar to how
|
|
|
|
* curl_easy_perform would work (but we don't want to use that, because
|
|
|
|
* we do not want to intermingle calls to curl_multi and curl_easy).
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
int run_one_slot(struct active_request_slot *slot,
|
|
|
|
struct slot_results *results);
|
|
|
|
|
2005-11-19 03:02:58 +08:00
|
|
|
#ifdef USE_CURL_MULTI
|
|
|
|
extern void fill_active_slots(void);
|
2007-09-11 11:02:34 +08:00
|
|
|
extern void add_fill_function(void *data, int (*fill)(void *));
|
2005-11-19 03:02:58 +08:00
|
|
|
extern void step_active_slots(void);
|
|
|
|
#endif
|
|
|
|
|
2011-12-14 08:11:56 +08:00
|
|
|
extern void http_init(struct remote *remote, const char *url,
|
|
|
|
int proactive_auth);
|
2005-11-19 03:02:58 +08:00
|
|
|
extern void http_cleanup(void);
|
2016-04-27 20:20:37 +08:00
|
|
|
extern struct curl_slist *http_copy_default_headers(void);
|
2005-11-19 03:02:58 +08:00
|
|
|
|
2016-02-03 12:09:14 +08:00
|
|
|
extern long int git_curl_ipresolve;
|
2005-11-19 03:02:58 +08:00
|
|
|
extern int active_requests;
|
2009-06-06 16:43:41 +08:00
|
|
|
extern int http_is_verbose;
|
2017-04-12 02:13:57 +08:00
|
|
|
extern ssize_t http_post_buffer;
|
http: hoist credential request out of handle_curl_result
When we are handling a curl response code in http_request or
in the remote-curl RPC code, we use the handle_curl_result
helper to translate curl's response into an easy-to-use
code. When we see an HTTP 401, we do one of two things:
1. If we already had a filled-in credential, we mark it as
rejected, and then return HTTP_NOAUTH to indicate to
the caller that we failed.
2. If we didn't, then we ask for a new credential and tell
the caller HTTP_REAUTH to indicate that they may want
to try again.
Rejecting in the first case makes sense; it is the natural
result of the request we just made. However, prompting for
more credentials in the second step does not always make
sense. We do not know for sure that the caller is going to
make a second request, and nor are we sure that it will be
to the same URL. Logically, the prompt belongs not to the
request we just finished, but to the request we are (maybe)
about to make.
In practice, it is very hard to trigger any bad behavior.
Currently, if we make a second request, it will always be to
the same URL (even in the face of redirects, because curl
handles the redirects internally). And we almost always
retry on HTTP_REAUTH these days. The one exception is if we
are streaming a large RPC request to the server (e.g., a
pushed packfile), in which case we cannot restart. It's
extremely unlikely to see a 401 response at this stage,
though, as we would typically have seen it when we sent a
probe request, before streaming the data.
This patch drops the automatic prompt out of case 2, and
instead requires the caller to do it. This is a few extra
lines of code, and the bug it fixes is unlikely to come up
in practice. But it is conceptually cleaner, and paves the
way for better handling of credentials across redirects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-28 16:31:45 +08:00
|
|
|
extern struct credential http_auth;
|
2005-11-19 03:02:58 +08:00
|
|
|
|
|
|
|
extern char curl_errorstr[CURL_ERROR_SIZE];
|
|
|
|
|
http: make redirects more obvious
We instruct curl to always follow HTTP redirects. This is
convenient, but it creates opportunities for malicious
servers to create confusing situations. For instance,
imagine Alice is a git user with access to a private
repository on Bob's server. Mallory runs her own server and
wants to access objects from Bob's repository.
Mallory may try a few tricks that involve asking Alice to
clone from her, build on top, and then push the result:
1. Mallory may simply redirect all fetch requests to Bob's
server. Git will transparently follow those redirects
and fetch Bob's history, which Alice may believe she
got from Mallory. The subsequent push seems like it is
just feeding Mallory back her own objects, but is
actually leaking Bob's objects. There is nothing in
git's output to indicate that Bob's repository was
involved at all.
The downside (for Mallory) of this attack is that Alice
will have received Bob's entire repository, and is
likely to notice that when building on top of it.
2. If Mallory happens to know the sha1 of some object X in
Bob's repository, she can instead build her own history
that references that object. She then runs a dumb http
server, and Alice's client will fetch each object
individually. When it asks for X, Mallory redirects her
to Bob's server. The end result is that Alice obtains
objects from Bob, but they may be buried deep in
history. Alice is less likely to notice.
Both of these attacks are fairly hard to pull off. There's a
social component in getting Mallory to convince Alice to
work with her. Alice may be prompted for credentials in
accessing Bob's repository (but not always, if she is using
a credential helper that caches). Attack (1) requires a
certain amount of obliviousness on Alice's part while making
a new commit. Attack (2) requires that Mallory knows a sha1
in Bob's repository, that Bob's server supports dumb http,
and that the object in question is loose on Bob's server.
But we can probably make things a bit more obvious without
any loss of functionality. This patch does two things to
that end.
First, when we encounter a whole-repo redirect during the
initial ref discovery, we now inform the user on stderr,
making attack (1) much more obvious.
Second, the decision to follow redirects is now
configurable. The truly paranoid can set the new
http.followRedirects to false to avoid any redirection
entirely. But for a more practical default, we will disallow
redirects only after the initial ref discovery. This is
enough to thwart attacks similar to (2), while still
allowing the common use of redirects at the repository
level. Since c93c92f30 (http: update base URLs when we see
redirects, 2013-09-28) we re-root all further requests from
the redirect destination, which should generally mean that
no further redirection is necessary.
As an escape hatch, in case there really is a server that
needs to redirect individual requests, the user can set
http.followRedirects to "true" (and this can be done on a
per-server basis via http.*.followRedirects config).
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-07 02:24:41 +08:00
|
|
|
enum http_follow_config {
|
|
|
|
HTTP_FOLLOW_NONE,
|
|
|
|
HTTP_FOLLOW_ALWAYS,
|
|
|
|
HTTP_FOLLOW_INITIAL
|
|
|
|
};
|
|
|
|
extern enum http_follow_config http_follow_config;
|
|
|
|
|
2007-12-11 05:36:09 +08:00
|
|
|
static inline int missing__target(int code, int result)
|
|
|
|
{
|
|
|
|
return /* file:// URL -- do we ever use one??? */
|
|
|
|
(result == CURLE_FILE_COULDNT_READ_FILE) ||
|
|
|
|
/* http:// and https:// URL */
|
|
|
|
(code == 404 && result == CURLE_HTTP_RETURNED_ERROR) ||
|
|
|
|
/* ftp:// URL */
|
|
|
|
(code == 550 && result == CURLE_FTP_COULDNT_RETR_FILE)
|
|
|
|
;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define missing_target(a) missing__target((a)->http_code, (a)->curl_result)
|
|
|
|
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 16:44:02 +08:00
|
|
|
/* Helpers for modifying and creating URLs */
|
|
|
|
extern void append_remote_object_url(struct strbuf *buf, const char *url,
|
|
|
|
const char *hex,
|
|
|
|
int only_two_digit_prefix);
|
|
|
|
extern char *get_remote_object_url(const char *url, const char *hex,
|
|
|
|
int only_two_digit_prefix);
|
|
|
|
|
2013-09-28 16:31:23 +08:00
|
|
|
/* Options for http_get_*() */
|
|
|
|
struct http_get_options {
|
|
|
|
unsigned no_cache:1,
|
http: make redirects more obvious
We instruct curl to always follow HTTP redirects. This is
convenient, but it creates opportunities for malicious
servers to create confusing situations. For instance,
imagine Alice is a git user with access to a private
repository on Bob's server. Mallory runs her own server and
wants to access objects from Bob's repository.
Mallory may try a few tricks that involve asking Alice to
clone from her, build on top, and then push the result:
1. Mallory may simply redirect all fetch requests to Bob's
server. Git will transparently follow those redirects
and fetch Bob's history, which Alice may believe she
got from Mallory. The subsequent push seems like it is
just feeding Mallory back her own objects, but is
actually leaking Bob's objects. There is nothing in
git's output to indicate that Bob's repository was
involved at all.
The downside (for Mallory) of this attack is that Alice
will have received Bob's entire repository, and is
likely to notice that when building on top of it.
2. If Mallory happens to know the sha1 of some object X in
Bob's repository, she can instead build her own history
that references that object. She then runs a dumb http
server, and Alice's client will fetch each object
individually. When it asks for X, Mallory redirects her
to Bob's server. The end result is that Alice obtains
objects from Bob, but they may be buried deep in
history. Alice is less likely to notice.
Both of these attacks are fairly hard to pull off. There's a
social component in getting Mallory to convince Alice to
work with her. Alice may be prompted for credentials in
accessing Bob's repository (but not always, if she is using
a credential helper that caches). Attack (1) requires a
certain amount of obliviousness on Alice's part while making
a new commit. Attack (2) requires that Mallory knows a sha1
in Bob's repository, that Bob's server supports dumb http,
and that the object in question is loose on Bob's server.
But we can probably make things a bit more obvious without
any loss of functionality. This patch does two things to
that end.
First, when we encounter a whole-repo redirect during the
initial ref discovery, we now inform the user on stderr,
making attack (1) much more obvious.
Second, the decision to follow redirects is now
configurable. The truly paranoid can set the new
http.followRedirects to false to avoid any redirection
entirely. But for a more practical default, we will disallow
redirects only after the initial ref discovery. This is
enough to thwart attacks similar to (2), while still
allowing the common use of redirects at the repository
level. Since c93c92f30 (http: update base URLs when we see
redirects, 2013-09-28) we re-root all further requests from
the redirect destination, which should generally mean that
no further redirection is necessary.
As an escape hatch, in case there really is a server that
needs to redirect individual requests, the user can set
http.followRedirects to "true" (and this can be done on a
per-server basis via http.*.followRedirects config).
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-07 02:24:41 +08:00
|
|
|
keep_error:1,
|
|
|
|
initial_request:1;
|
2009-06-06 16:43:53 +08:00
|
|
|
|
2013-09-28 16:31:23 +08:00
|
|
|
/* If non-NULL, returns the content-type of the response. */
|
|
|
|
struct strbuf *content_type;
|
2013-09-28 16:32:02 +08:00
|
|
|
|
2014-05-22 17:30:05 +08:00
|
|
|
/*
|
|
|
|
* If non-NULL, and content_type above is non-NULL, returns
|
|
|
|
* the charset parameter from the content-type. If none is
|
|
|
|
* present, returns an empty string.
|
|
|
|
*/
|
|
|
|
struct strbuf *charset;
|
|
|
|
|
2013-09-28 16:32:02 +08:00
|
|
|
/*
|
|
|
|
* If non-NULL, returns the URL we ended up at, including any
|
|
|
|
* redirects we followed.
|
|
|
|
*/
|
|
|
|
struct strbuf *effective_url;
|
http: update base URLs when we see redirects
If a caller asks the http_get_* functions to go to a
particular URL and we end up elsewhere due to a redirect,
the effective_url field can tell us where we went.
It would be nice to remember this redirect and short-cut
further requests for two reasons:
1. It's more efficient. Otherwise we spend an extra http
round-trip to the server for each subsequent request,
just to get redirected.
2. If we end up with an http 401 and are going to ask for
credentials, it is to feed them to the redirect target.
If the redirect is an http->https upgrade, this means
our credentials may be provided on the http leg, just
to end up redirected to https. And if the redirect
crosses server boundaries, then curl will drop the
credentials entirely as it follows the redirect.
However, it, it is not enough to simply record the effective
URL we saw and use that for subsequent requests. We were
originally fed a "base" url like:
http://example.com/foo.git
and we want to figure out what the new base is, even though
the URLs we see may be:
original: http://example.com/foo.git/info/refs
effective: http://example.com/bar.git/info/refs
Subsequent requests will not be for "info/refs", but for
other paths relative to the base. We must ask the caller to
pass in the original base, and we must pass the redirected
base back to the caller (so that it can generate more URLs
from it). Furthermore, we need to feed the new base to the
credential code, so that requests to credential helpers (or
to the user) match the URL we will be requesting.
This patch teaches http_request_reauth to do this munging.
Since it is the caller who cares about making more URLs, it
seems at first glance that callers could simply check
effective_url themselves and handle it. However, since we
need to update the credential struct before the second
re-auth request, we have to do it inside http_request_reauth.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-28 16:34:05 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If both base_url and effective_url are non-NULL, the base URL will
|
|
|
|
* be munged to reflect any redirections going from the requested url
|
|
|
|
* to effective_url. See the definition of update_url_from_redirect
|
|
|
|
* for details.
|
|
|
|
*/
|
|
|
|
struct strbuf *base_url;
|
2018-03-16 01:31:38 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If not NULL, contains additional HTTP headers to be sent with the
|
|
|
|
* request. The strings in the list must not be freed until after the
|
|
|
|
* request has completed.
|
|
|
|
*/
|
|
|
|
struct string_list *extra_headers;
|
2013-09-28 16:31:23 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Return values for http_get_*() */
|
2009-06-06 16:43:53 +08:00
|
|
|
#define HTTP_OK 0
|
|
|
|
#define HTTP_MISSING_TARGET 1
|
|
|
|
#define HTTP_ERROR 2
|
|
|
|
#define HTTP_START_FAILED 3
|
2010-04-02 06:14:35 +08:00
|
|
|
#define HTTP_REAUTH 4
|
|
|
|
#define HTTP_NOAUTH 5
|
2009-06-06 16:43:53 +08:00
|
|
|
|
|
|
|
/*
|
2012-03-28 16:41:54 +08:00
|
|
|
* Requests a URL and stores the result in a strbuf.
|
2009-06-06 16:43:53 +08:00
|
|
|
*
|
|
|
|
* If the result pointer is NULL, a HTTP HEAD request is made instead of GET.
|
|
|
|
*/
|
2013-09-28 16:31:23 +08:00
|
|
|
int http_get_strbuf(const char *url, struct strbuf *result, struct http_get_options *options);
|
2009-06-06 16:43:53 +08:00
|
|
|
|
Make walker.fetch_ref() take a struct ref.
This simplifies a few things, makes a few things slightly more
complicated, but, more importantly, allows that, when struct ref can
represent a symref, http_fetch_ref() can return one.
Incidentally makes the string that http_fetch_ref() gets include "refs/"
(if appropriate), because that's how the name field of struct ref works.
As far as I can tell, the usage in walker:interpret_target() wouldn't have
worked previously, if it ever would have been used, which it wouldn't
(since the fetch process uses the hash instead of the name of the ref
there).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-27 03:53:09 +08:00
|
|
|
extern int http_fetch_ref(const char *base, struct ref *ref);
|
2007-12-11 07:08:25 +08:00
|
|
|
|
2009-06-06 16:43:59 +08:00
|
|
|
/* Helpers for fetching packs */
|
|
|
|
extern int http_get_info_packs(const char *base_url,
|
|
|
|
struct packed_git **packs_head);
|
|
|
|
|
2011-03-16 15:08:34 +08:00
|
|
|
struct http_pack_request {
|
2009-06-06 16:44:01 +08:00
|
|
|
char *url;
|
|
|
|
struct packed_git *target;
|
|
|
|
struct packed_git **lst;
|
|
|
|
FILE *packfile;
|
2018-05-19 09:56:37 +08:00
|
|
|
struct strbuf tmpfile;
|
2009-06-06 16:44:01 +08:00
|
|
|
struct active_request_slot *slot;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct http_pack_request *new_http_pack_request(
|
|
|
|
struct packed_git *target, const char *base_url);
|
|
|
|
extern int finish_http_pack_request(struct http_pack_request *preq);
|
|
|
|
extern void release_http_pack_request(struct http_pack_request *preq);
|
|
|
|
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 16:44:02 +08:00
|
|
|
/* Helpers for fetching object */
|
2011-03-16 15:08:34 +08:00
|
|
|
struct http_object_request {
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 16:44:02 +08:00
|
|
|
char *url;
|
2018-05-19 09:56:37 +08:00
|
|
|
struct strbuf tmpfile;
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 16:44:02 +08:00
|
|
|
int localfile;
|
|
|
|
CURLcode curl_result;
|
|
|
|
char errorstr[CURL_ERROR_SIZE];
|
|
|
|
long http_code;
|
|
|
|
unsigned char sha1[20];
|
|
|
|
unsigned char real_sha1[20];
|
|
|
|
git_SHA_CTX c;
|
2011-06-11 02:52:15 +08:00
|
|
|
git_zstream stream;
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 16:44:02 +08:00
|
|
|
int zret;
|
|
|
|
int rename;
|
|
|
|
struct active_request_slot *slot;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct http_object_request *new_http_object_request(
|
|
|
|
const char *base_url, unsigned char *sha1);
|
|
|
|
extern void process_http_object_request(struct http_object_request *freq);
|
|
|
|
extern int finish_http_object_request(struct http_object_request *freq);
|
|
|
|
extern void abort_http_object_request(struct http_object_request *freq);
|
|
|
|
extern void release_http_object_request(struct http_object_request *freq);
|
|
|
|
|
2016-05-23 21:44:02 +08:00
|
|
|
/* setup routine for curl_easy_setopt CURLOPT_DEBUGFUNCTION */
|
|
|
|
void setup_curl_trace(CURL *handle);
|
2005-11-19 03:02:58 +08:00
|
|
|
#endif /* HTTP_H */
|