I've been looking into the HttpServletRequest API (Java) which has the getRequestURI and getRequestURL methods. That made me look into: https://www.rfc-editor.org/rfc/rfc7230#section-5.3 As I understand getRequestURI returns the value from the first line of the http request which is a relative path to the resource most of the time unless the origin server is behind an inbound proxy in which case it must be an absolute URI. I guess most origin servers of the popular websites on the internet belong to that category which means that the URI in the raw http request should be the absoluteUri (from the http specs) but I haven't managed to find an example of this anywhere. Can a browser really know if it sends its requests to an inbound proxy or directly to the origing server? Is there any practical value in that absoluteUri concept in the http specs? Because the Host header field is always sent in HTTP 1.1 requests. Did that part of the specification had some practical value in the time of HTTP 1.0 when there was no Host header field yet?
I think you might be confused about the type of proxy being discussed. It looks like the RFC is referring to a forward-proxy where you make a request to a different server via another one (and the client tells the proxy where to forward traffic to).
With a reverse proxy, you're right, the client doesn't know that a request has been proxied to another server.