Would it be possible to add a cross-registrable-domain origin to WPT? That is, all of the {{domain[*]}} options are rooted in web-platform.test at the moment, which makes it super-tough to test things like https://tools.ietf.org/html/draft-west-first-party-cookies-06. not-web-platform.test would be ideal (along with not-w3c-test.org, of course).
This would be good for document.domain and WebAuthN too. @jgraham @plehegar?
@sideshowbarker do you remember what we did for w3c-test.org? Maybe we can get @w3c-test-alt.org?
@sideshowbarker do you remember what we did for w3c-test.org? Maybe we can get @w3c-test-alt.org?
Don’t know what we did for w3c-test.org because I don’t recall being directly involved in the registration. Dunno who handled it, but anyway if we can first just agree on what name we want, I’m sure we can get it registered
I have a slight preference for something a name without "alt", but maybe I'm being overly sensitive. "w3c-test-2.org" and "web-platform-2.test" locally? Would also be good to have syntax to address it in wptserve.
(We also need this for SharedArrayBuffer.)
Sorry, I was planning to do the wptserve side of this and got swamped. I was thinking of web-platform-alternate.test (I don't really like numbers in names), but happy to go ahead with anything people are happy with.
not-w3c-test.org? tset-c3w.org? I have no strong opinions, as long as it's not the same eTLD+1, and accessible via {{domains[whatever]}}.
@jgraham I'm happy with that name and also those that @mikewest proposes.
I'm requesting not-w3c-test.org to complement w3c-test.org.
Ping? If y'all roll something out, I'll land some tests using it. :P
Ping?
I'm pushing harder. I don't have a better answer within 2 weeks, I'll look at alternatives (ie non-W3C ones).
Thanks, @plehegar!
That said, the W3C buying a domain is welcome, but it's not actually the most important bit. :)
If we're going to support a separate domain, we need to teach wptserve about another endpoint. That's the work @jgraham mentioned above, and the bit I intended to be pinging above.
www.not-w3c-test.org now exists.
@mikewest Does the existence of http://www.not-w3c-test.org/ satisfy the original issue? If there is more to be done, can you describe it here or open a new issue (closing this one)?
No, this requires changes in wptrunner and the documentation so that the domain is usable.
Any update on this? I'd really like to be able to port some cookie tests to WPT.
So, AIUI, we need a further hostname, which needs changes in the config file (as the hostname is configurable) and in wptserve to listen on those, and add it to the list (lists?) of known host names in wptrunner.
The wptrunner changes should probably try and avoid making #6556 worse.
Given that this seems to be blocking @mikewest from sharing tests for features in Chromium, I'll call this priority:roadmap so that we don't lose track of it. @gsnedders, is this a 1-day effort? If so, could you treat it as a P3 for this quarter?
@foolip doing it properly is probably a couple of days work, given the technical debt we already have around the hostname stuff.
Hmm, OK. I guess I'll leave the roadmap label for now, but if someone tries to work on this and fails, maybe we should downgrade to backlog in favor of cleaning up that technical debt.
@gsnedders @foolip Any update on this? Should we keep it as roadmap or downgrade to backlog?
Roadmap sounds right, I'd default to that for any request from any implementer who's already doing a lot of wpt work.
This came up again in https://www.w3.org/2017/11/06-webappsec-minutes.html#item16.
I think this is technically very straightforward now. We have not-w3c-test.org, and for local testing we'd use not-web-platform.test. @gsnedders @mattl, would either of you like to spend a bit of time seeing if this is in fact trivial, or if there are more blockers?
Are there existing manual tests that need this?
@JKereliuk manual tests have the same limitation with this missing...
@mattl are you currently working on this? if not, I'll take it over.
All yours! Sorry for hogging it and then not doing it.
For context, Geoffrey and I thought this would make sense since the other Google OKRs involving him are either done or blocked right now.
Ping! @marumari tells me that Mozilla is actively working on SameSite cookies, and I can't upstream tests until this bug is taken care of.
This is high on the Resolve known important infra issues for wpt list. @gsnedders, do you have an estimate?
I'll get this done before reviewing more PRs from the holidays, then! Let's aim for end of next week, with an open, working PR this week.
Sounds good, thanks Geoffrey!
So, status update:
https://github.com/w3c/web-platform-tests/pull/8614 is taking more time than I expected, but I think is now basically done. I've spent today writing some tests for it, and found one or two other issues around wptrunner. I'll start on this, on top of that branch, tomorrow or Monday; I don't think this will take more than a day or two, so hopefully we get it all landed in January.
So this proved to be much more painful than I expected, and I spent most of February fighting fires.
However, #9258 renamed external_host → host and host → host_ip which got rid of the most awkward part, and allowed me to write #10078 quickly this afternoon which means this finally is actually easy (and hopefully like a four-line patch).
@gsnedders do you have an update? https://github.com/w3c/web-platform-tests/pull/10078 is merged, looks like action is now in https://github.com/w3c/web-platform-tests/pull/10166?
Most helpful comment
Given that this seems to be blocking @mikewest from sharing tests for features in Chromium, I'll call this priority:roadmap so that we don't lose track of it. @gsnedders, is this a 1-day effort? If so, could you treat it as a P3 for this quarter?