search

web-platform-tests / rfcs

web-platform-tests RFCs
75 stars 63 forks source link

RFC-118: Proxy everything to WPT server instead of PAC #118

Closed noamr closed 1 year ago

noamr commented 1 year ago

The PAC implementation reached a roadblock since Mac (Safari+Chrome) does not allow programmatic setting of PAC URLs. Proposing a simpler solution that would work for more tests that require a proxy.

noamr commented 1 year ago

@jgraham sorry to bug you with more proxy stuff. Thoughts?

jgraham commented 1 year ago

It sounds simpler at least. If you have an experimental implementation I think that would help me reason about any tradeoffs or issues that I'm not immediately thinking of.

noamr commented 1 year ago

It sounds simpler at least. If you have an experimental implementation I think that would help me reason about any tradeoffs or issues that I'm not immediately thinking of.

Sure, I'll post a WIP PR. It's based on the PAC implementation so at least that work was not a waste :)

gsnedders commented 1 year ago

What's the intention as to how to proxy everything?

noamr commented 1 year ago

What's the intention as to how to proxy everything?

Pass the WPT server's address as an HTTP proxy to the browser prefs. All requests would go to the WPT server, and some of them would have a Host header. It should generally "just work".

noamr commented 1 year ago

Implementation: https://github.com/web-platform-tests/wpt/pull/34911

gsnedders commented 1 year ago

The PAC implementation reached a roadblock since Mac (Safari+Chrome) does not allow programmatic setting of PAC URLs.

As you've now found with https://github.com/web-platform-tests/wpt/pull/34911, the limitation with Safari is an inability to set proxy configuration as all (this is rdar://36854985), rather than there being any different/special with PACs. (I don't know what the situation is for Chrome on macOS?)

noamr commented 1 year ago

The PAC implementation reached a roadblock since Mac (Safari+Chrome) does not allow programmatic setting of PAC URLs.

As you've now found with web-platform-tests/wpt#34911, the limitation with Safari is an inability to set proxy configuration as all (this is rdar://36854985), rather than there being any different/special with PACs. (I don't know what the situation is for Chrome on macOS?)

Right. Still I think using the proxy-all technique makes everything simpler.

jgraham commented 1 year ago

I imagine the usecase it doesn't support is adding latency early in the connection (by busy-looping in the PAC). Is that still an important requirement?

noamr commented 1 year ago

I imagine the usecase it doesn't support is adding latency early in the connection (by busy-looping in the PAC). Is that still an important requirement?

It's less important in itself.

noamr commented 1 year ago

Ping?

noamr commented 1 year ago

Abandoning this as RFC112 (PAC) covers this sufficiently and the issue in Chrome has been resolved.

jgraham commented 1 year ago

Do we have any reason to believe that this might be more likely to be usable in Safari before the PAC approach?

noamr commented 1 year ago

Do we have any reason to believe that this might be more likely to be usable in Safari before the PAC approach?

No. As @gsnedders had mentioned, the Safari issue is not related to PAC vs. regular proxy, it's only about setting proxy at all in WebDriver.