You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One general concern is that we want components to be version-agnostic so that the HTTP version can be upgraded over time by the host without breaking existing code. IIUC, for this reason, the HTTP version isn't included in the HTTP semantics which, thus far, we've been mirroring with HTTP interface. On the other hand, it does seem like there are plenty of benign use cases where you might want to, e.g., log the version. One idea is that requests could have an optional child resource (hanging off the request resource), say called connection-info, that had various wire format details including HTTP version but also, say, client IP address (which I've seen use cases for and is also not part of HTTP semantics).
Activity
lukewagner commentedon Apr 20, 2023
Yeah, I can see how that would be useful.
One general concern is that we want components to be version-agnostic so that the HTTP version can be upgraded over time by the host without breaking existing code. IIUC, for this reason, the HTTP version isn't included in the HTTP semantics which, thus far, we've been mirroring with HTTP interface. On the other hand, it does seem like there are plenty of benign use cases where you might want to, e.g., log the version. One idea is that requests could have an optional child resource (hanging off the
requestresource), say calledconnection-info, that had various wire format details including HTTP version but also, say, client IP address (which I've seen use cases for and is also not part of HTTP semantics).