blob: 5e39b86353ed55da6d48cc85e7d58becd22029ce (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
#![cfg_attr(docsrs, feature(doc_auto_cfg, doc_cfg))]
#![doc = include_str!("../README.md")]
// TODO hss: Add complete suite of warnings here.
#![allow(dead_code, unused_variables)] // TODO hss remove.
mod err;
mod keys;
mod status;
mod streamproxy;
mod svc;
use async_trait::async_trait;
pub use err::Error;
pub use status::OnionServiceStatus;
pub use svc::OnionService;
/// A Result type describing an onion service operation.
pub type Result<T> = std::result::Result<T, Error>;
/// An object that knows how to handle stream requests.
#[async_trait]
pub trait StreamHandler {
/// Handle an incoming stream request on a given onion service.
//
// TODO hss: the `circ_info` argument should have data about the circuit on
// which the request arrived. If the client authenticated, it might tell us
// who they are. Or it might have information about how many requests
// (and/or failed requests) we've gotten on the circuit.
//
// TODO hss: The `circ_info` argument should at a minimum include the
// circuit; ideally in a form that we can get a weak reference to it, and
// use it in the key of a `PtrWeakKeyHashMap`. (Or we could stick the info
// in the circuit itself somehow, and access it as a Box<dyn Any>, but
// that's a bit sketchy type-wise.)
//
// TODO hss: the `stream` argument should be an IncomingStream from
// tor-proto, but that branch is not yet merged as of this writing.
async fn handle_request(&self, circ_info: &(), stream: ());
}
mod mgr {
// TODO hss: Do we want to have the notion of a collection of onion services,
// running in tandem? Or is that a higher-level crate, possibly a part of
// TorClient?
}
|
