Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where is the value of the Origin header set? #368

Closed
zcorpan opened this issue Oct 11, 2021 · 2 comments · Fixed by #370
Closed

Where is the value of the Origin header set? #368

zcorpan opened this issue Oct 11, 2021 · 2 comments · Fixed by #370
Assignees

Comments

@zcorpan
Copy link
Member

zcorpan commented Oct 11, 2021

Origin request header for WebTransport was added in response to #60

I 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

Establish a WebTransport session on connection

https://w3c.github.io/webtransport/#session-establish says:

To establish a WebTransport session, follow [WEB-TRANSPORT-HTTP3] section 3.3.

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/#section-3.3 says

An "Origin"
header [RFC6454] MUST be provided within the request.

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.

@yutakahirano
Copy link
Contributor

I believe you want to use transport's relevant settings object's origin, serialized and isomorphic encoded. cc @annevk to confirm.

Yes. We can explicitly state that in this spec.

@martinthomson
Copy link
Member

Want to mark this for MVS milestone?

martinthomson added a commit to martinthomson/webtransport that referenced this issue Oct 13, 2021
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.

Closes w3c#175.
@yutakahirano yutakahirano added this to the Minimum viable ship milestone Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants