Unfortunately there are differences in opinion on the meaning of upstream/downstream. When talking about system architecture, I define it as follows:
Given a system of concern, systems that initiate messages/data exchange to the system of concern are upstream systems, and systems that the system of concern depends on (i.e. those to which my system initiates data exchange) are downstream systems.
This link from ibm describing interactions with one of their products corroborates this view: Integrating with upstream and downstream systems
An upstream system is any system that sends data to the Collaboration Server system. A downstream system is a system that receives data from the Collaboration Server system.
Given the terminology 'upstream' and 'downstream' it may help to make an analogy with a river. If you drop a message (data) in the river it flows from upstream (initiator) to downstream (receiver).
Anecdotally, I've found that architects and middleware developers use this definition and web developers the opposite (maybe due to 'upload'ing).
With Event timelines, an event is upstream when it happens before a point on the timeline (i.e. triggers another event) and downstream when it happens afterwards (i.e. received the event). What is upstream and what is downstream in a sequence of events, therefore, depends on where you are in the timeline. An event can be both downstream and upstream, depending on whether your starting point is before or after it.
As @Jack notes RFC7230 tools.ietf.org/html/rfc7230#section-2.3tools.ietf.org/html/rfc7230#section-2.3 has this:
The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all
messages flow from upstream to downstream
