in the thread-calling http interface.
Specifying a content-type header of application/x-urb-jam will make the
request body be interpreted as a uw-encoded jammed noun, rather than
json.
Specifying an accept header of application/x-urb-jam will make the
thread result in the response body be rendered as a uw-encoded jammed
noun, rather than json.
For the latter, the output mark becomes unused, since we can just
"render" the resulting noun directly, without needing to explicitly
convert it. (This assumes that converting any mark to %noun will always
result in the same noun, which isn't guaranteed in theory, but is always
the case in practice.)
This prepares spider for use in a nouns-based version of js-http-api.
It appears that bb8ba24 merged changes to /ted/test from #6790 and #6896
incorrectly, as the thread no longer compiled.
Because the former PR included the change made to the latter (printing
with slog priority 3 in case of failure), the minimum viable fix is
taking the contents of /ted/test from #6790 and using those as-is.
However, that had hidden success prints behind a "quiet" flag, and
provided no way of configuring that from outside the thread. So
additionally, we expand the ""vase parsing"" performed on the thread's
argument, such that an optional _first_ parameter of a quiet=? may be
passed.
It appears that bb8ba24 merged changes to /ted/test from #6790 and #6896
incorrectly, as the thread no longer compiled.
Because the former PR included the change made to the latter (printing
with slog priority 3 in case of failure), the minimum viable fix is
taking the contents of /ted/test from #6790 and using those as-is.
However, that had hidden success prints behind a "quiet" flag, and
provided no way of configuring that from outside the thread. So
additionally, we expand the ""vase parsing"" performed on the thread's
argument, such that an optional _first_ parameter of a quiet=? may be
passed.
We always update the eauth endpoint based on new logins from the local
identity. We also let the user configure a hardcoded endpoint url. In
both cases, we update a recency timestamp for the endpoint, to help us
keep our scry namespace responses immutable.
However, we even updated this timestamp if the visible endpoint didn't
change. That is, if the new value was identical, or if the auto-detected
endpoint changed, but it was actively being overridden by a
user-configured url.
Here, we update the stored timestamp only if the visible url actually
changed. This should help us respond to (remote) scry requests more
consistently.
(See also the note in +send-keen.)
Eyre already looks at the Forwarded header for the original requester's
IP address, and the security level of the connection. Some proxies may
modify the original Host header, but still provide the original in the
Forwarded header. So, if present, we respect that.
