| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This reflects that it is expected for an HTTP GET body. It is okay
because it is only used in tor-dirmgr, which only performs GET request
anyways.
|
| |
|
|
|
|
|
|
|
| |
This commit fixes the previous check to only fail on empty GET
responses. For this, it introduces a `method` field into
`DirResponse`, which is required to determine the method there.
Doing this is reasonable for an HTTP client, as responses have different
meanings depending on the request method used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit disallows empty responses with a status code 200.
From a pure HTTP level, this is totally valid, but it does not make any
sense in the context of the Tor directory protocol, where an empty
response only makes sense with a 404.
The motivation for this is that a work-in-progress
tor_dirclient::send_request wrapper for tor-dirserver passes the
response into the parse2 multiple function which returns a Vec<T>.
Interfacing code would then always have to check for an empty length and
do respective error handling, which should already fail at an earlier
level (tor-dirclient) instead.
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| |
|
|
|
|
| |
This entirely removes the requirement on ClientCirc.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
1) It's the last hop that matters, not the first.
2) The last hop could conceivably be virtual, making the source anonymous.
(Though this never happens in Arti today.)
|
| |
|
|
|
|
|
|
| |
This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become
fallible (we can't unwrap the result, because when a circuit is closed,
its state gets removed from the `TunnelSharedState`, but its
`ClientCirc` handle continues to exist, so any attempt to retrieve the
state will result in an `Err`).
|
| |
|
|
|
|
| |
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
|
| | |
|
| |
|
|
|
|
|
|
| |
The HTTP status text is often useful for diagnosing errors. Tor
directory and hsdir caches frequently put useful messages there,
especially when rejecting an uploaded document.
Inspired by #1142.
|
| |
|
|
|
| |
Not checking whether the response is successful can have unintended
consequences.
|
| | |
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceInfo primarily appears in errors, here and in (indirectly)
tor-dirmgr.
This
1. Makes the errors smaller
2. Redacts (currently, scrubs) the chantarget when safe logging is enabled
This commit therefore deals with both tor-dirmgr and tor-dirclient
errors, from the pov of error information that should become sensitive
as part of bridge support.
The error pyaloads directly in tor_dirmgr/src/err.rs don't seem to
contain anything in that category.
|
| |
|
|
|
| |
This is the missing one of the full set. It turns out that I wanted
this rather than the non-consuming output_string.
|
| |
|
|
| |
This gives callers a nice error type with source and everything.
|
| | |
|
| |
|
|
| |
I want this for testing. It seems friendly to provide it, though.
|
| |
|
|
|
| |
These don't check errors and are therefore quite hazardous.
I'm going to introduce a more cooked version in a moment.
|
| |
|
|
|
|
|
| |
These errors no longer use Debug to dump the `Option<SourceInfo>`, but
instead produce reasonable text. Also, I've fixed the SourceInfo
Display implementation so that it now says that it got the error
"from $source via $circuit" rather than the other way around.
|
| | |
|
| |
|
|
| |
(Also, implement Display for tor_dirclient::SourceInfo).
|
| |
|
|
|
|
|
|
|
|
| |
This commit refactors the dirclient error type into two cases:
errors when constructing a circuit, and errors that occur once we
already have a one-hop circuit. The latter can usually be
attributed to the specific cache we're talking to.
This commit also adds a function to expose the information about
which directory gave us the info.
|
| | |
|
| | |
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
