pub struct HttpRegistry<'cfg> {
Show 14 fields index_path: Filesystem, cache_path: Filesystem, source_id: SourceId, config: &'cfg Config, url: Url, multi: Multi, requested_update: bool, downloads: Downloads<'cfg>, multiplexing: bool, fresh: HashSet<PathBuf>, fetch_started: bool, registry_config: Option<RegistryConfig>, auth_required: bool, login_url: Option<Url>,
}
Expand description

A registry served by the HTTP-based registry API.

This type is primarily accessed through the RegistryData trait.

HttpRegistry implements the HTTP-based registry API outlined in RFC 2789. Read the RFC for the complete protocol, but roughly the implementation loads each index file (e.g., config.json or re/ge/regex) from an HTTP service rather than from a locally cloned git repository. The remote service can more or less be a static file server that simply serves the contents of the origin git repository.

Implemented naively, this leads to a significant amount of network traffic, as a lookup of any index file would need to check with the remote backend if the index file has changed. This cost is somewhat mitigated by the use of HTTP conditional fetches (If-Modified-Since and If-None-Match for ETags) which can be efficiently handled by HTTP/2.

Fields§

§index_path: Filesystem§cache_path: Filesystem§source_id: SourceId§config: &'cfg Config§url: Url

Store the server URL without the protocol prefix (sparse+)

§multi: Multi

HTTP multi-handle for asynchronous/parallel requests.

§requested_update: bool

Has the client requested a cache update?

Only if they have do we double-check the freshness of each locally-stored index file.

§downloads: Downloads<'cfg>

State for currently pending index downloads.

§multiplexing: bool

Does the config say that we can use HTTP multiplexing?

§fresh: HashSet<PathBuf>

What paths have we already fetched since the last index update?

We do not need to double-check any of these index files since we have already done so.

§fetch_started: bool

Have we started to download any index files?

§registry_config: Option<RegistryConfig>

Cached registry configuration.

§auth_required: bool

Should we include the authorization header?

§login_url: Option<Url>

Url to get a token for the registry.

Implementations§

Get the cached registry configuration, if it exists.

Get the registry configuration.

Trait Implementations§

Performs initialization for the registry. Read more
Returns the path to the index. Read more
Validates that the global package cache lock is held. Read more
Is the local cached data up-to-date?
Loads the JSON for a specific named package from the index. Read more
Loads the config.json file and returns it. Read more
Invalidates locally cached data.
Prepare to start downloading a .crate file. Read more
Finish a download by saving a .crate file to disk. Read more
Returns whether or not the .crate file is already downloaded.
Block until all outstanding Poll::Pending requests are Poll::Ready.

Auto Trait Implementations§

Blanket Implementations§

Gets the TypeId of self. Read more
Immutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more

Returns the argument unchanged.

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

Should always be Self
The type returned in the event of a conversion error.
Performs the conversion.
The type returned in the event of a conversion error.
Performs the conversion.

Layout§

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference’s “Type Layout” chapter for details on type layout guarantees.

Size: 672 bytes