Re: Working Group Last Call: Incremental HTTP Messages

2025年10月17日(金) 12:33 Willy Tarreau <w@1wt.eu>:

> On Thu, Oct 16, 2025 at 05:23:32PM -0700, Rory Hewitt wrote:
> > ...and yet, to literally millions of people who are somewhat involved in
> > the technical side of "the Internet", the words "downstream" and
> "upstream"
> > are STILL commonly taken to mean "to the client" and "to the server". I
> > think everyone on this list understands that.
>
> FWIW I personally don't fully agree. I'm fine with this when speaking about
> the response, not the request. For me "upstream" means "where it comes
> from"
> and "downastream" means " where it goes". I guess that most users see it
> like this when considering their view as a client retrieving an object. But
> when it comes to HTTP messages, specifically requests, for me "upstream" is
> the side which sends the request and "downstream" is the side I'm
> forwarding
> it to. I've even found in the haproxy doc a paragraph saying that the
> logged
> accept date should match the one found in an upstream firewall which passed
> the request.
>
> But yes, speaking of caches (which mostly focus on caching contents),
> "upstream" and "downstream" intuitively focus on the response flow and are
> used as you described.
>

I share this observation.

When talking about content delivery, downstream is the clients. But when
talking about HTTP messages (or QUIC *streams*), downstream is the node
that receives the message.

As to what we should do with the draft, I get the confusion, but I agree
with Roy that the ship has sailed.

RFC 9110 defines "upstream" / "downstream" and other core specifications
use them, assuming that the readers understand the semantics. Based on
that, I do not think there is a lot of value in using a different phrasing
or re-clarifying the meaning in one of the extensions.



>
> Overall, I'd use these terms with caution depending on the context.
>
> Just my two cents,
> Willy
>
>

-- 
Kazuho Oku