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
The Fetch spec normally adds the Origin header with the right value for a request when performing a HTTP-network-or-cache fetch, but WebTransport doesn't use a request or the HTTP fetch entry point.
The text was updated successfully, but these errors were encountered:
In looking into this text and the related specifications I decided that
it would be better to address the risk of request forgery in the
protocol specifications. Right now, they say nothing about this
problem, but they really should. I'm going to open an issue.
On the assumption that the protocol documents address this problem
adequately, then this document doesn't need to concern itself with the
problem. It is enough to remove any false claims and defer to the
protocol spec.
This contains a tweak to the adjacent text for the Origin field (w3c#368),
but it doesn't fix that issue.
Closesw3c#175.
Origin
request header for WebTransport was added in response to #60I tried to find out what the value of this header will be, and did not find it.
https://w3c.github.io/webtransport/#initialize-webtransport-over-http says in step 8
https://w3c.github.io/webtransport/#session-establish says:
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/#section-3.3 says
So, any value?
I believe you want to use transport's relevant settings object's origin, serialized and isomorphic encoded. cc @annevk to confirm.
The Fetch spec normally adds the
Origin
header with the right value for a request when performing a HTTP-network-or-cache fetch, but WebTransport doesn't use a request or the HTTP fetch entry point.The text was updated successfully, but these errors were encountered: