| Safe Haskell | None |
|---|---|
| Language | GHC2021 |
Ecluse.Core.Server.Pipeline.Tarball.Relay
Description
The pure HTTP relay-mechanics behind the tarball pipeline: the serve-mode plumbing that shapes an upstream artifact request, the dispatch that relays its response, and the verdict that judges a public relay from its status and headers alone.
These are the artifact path's transport mechanics, factored out of the
Tarball handler orchestration. They operate on
Status, ResponseHeaders, and Request values and the metrics
and log ports, and touch neither the Handler reader nor the
mount's PackumentDeps. The handler half composes them
one-way, adapting its route-owned replies onto the RelayResponder this layer drives.
Synopsis
- data ArtifactServe
- withMethod :: ArtifactServe -> Request -> Request
- withValidators :: RequestHeaders -> Request -> Request
- relayUpstreamWhen :: ArtifactServe -> Manager -> Request -> (Status -> Bool) -> (Status -> ResponseHeaders -> IO (Status, ResponseHeaders)) -> RelayResponder response -> IO (Maybe response)
- acceptArtifact :: Status -> Bool
- relayArtifact :: Status -> ResponseHeaders -> (Status, ResponseHeaders)
- data RelayVerdict
- relayVerdict :: Status -> ResponseHeaders -> RelayVerdict
- observeRelayAnomaly :: KatipContext m => MetricsPort -> PackageName -> Version -> RelayVerdict -> m ()
Serve mode
data ArtifactServe Source #
Shaping the upstream artifact request
withMethod :: ArtifactServe -> Request -> Request Source #
withValidators :: RequestHeaders -> Request -> Request Source #
Relaying the upstream response
relayUpstreamWhen :: ArtifactServe -> Manager -> Request -> (Status -> Bool) -> (Status -> ResponseHeaders -> IO (Status, ResponseHeaders)) -> RelayResponder response -> IO (Maybe response) Source #
acceptArtifact :: Status -> Bool Source #
relayArtifact :: Status -> ResponseHeaders -> (Status, ResponseHeaders) Source #
Judging the public relay
data RelayVerdict Source #
What the public leg relayed, judged at relay time from the status and headers
alone -- the body always relays verbatim, and client-side plus worker
dist.integrity verification stay the guarantors of the bytes. Header-only by
design: nothing here hashes, buffers, or inspects a body, and the private leg
computes no verdict at all.
The verdict's consumer side: a non-RelayedArtifact is logged and counted
(ecluse.serve.relay.anomalies), and only a RelayedArtifact enqueues the
demand-driven mirror job -- a relayed upstream miss used to enqueue a doomed job
that the worker could only drop after a metadata round trip.
Constructors
| RelayedArtifact | A success whose headers look like the admitted artifact (a relayed
|
| RelayedOddShape Text | A success that does not look like an artifact (carried, bounded reason). |
| RelayedNonSuccess Status | A non-success passed through verbatim (carried). |
Instances
| Show RelayVerdict Source # | |
Defined in Ecluse.Core.Server.Pipeline.Tarball.Relay Methods showsPrec :: Int -> RelayVerdict -> ShowS # show :: RelayVerdict -> String # showList :: [RelayVerdict] -> ShowS # | |
| Eq RelayVerdict Source # | |
Defined in Ecluse.Core.Server.Pipeline.Tarball.Relay | |
relayVerdict :: Status -> ResponseHeaders -> RelayVerdict Source #
Judge one public relay from its status and headers. A 304 is a clean
pass-through (the relayed validators matched); any other non-2xx is the relayed
non-success; a 2xx whose Content-Type is textual (text/*, or JSON where a
tarball was admitted) is the odd shape -- an upstream answering a success that is
visibly not the artifact. An absent or binary content type is taken as the
artifact: this is a header-only tripwire, not a validator (integrity
verification owns the bytes).
The admitted metadata's declared size is deliberately not compared against
Content-Length: for npm the declared size is the unpacked-tree size
(dist.unpackedSize), which never equals the transfer length, so the comparison
would flag every healthy relay.
observeRelayAnomaly :: KatipContext m => MetricsPort -> PackageName -> Version -> RelayVerdict -> m () Source #