Interaction with proxies

[igrigorik]

(feedback from @mcmanus)

The https:// tunnel through the proxy isn't a TCP/IP/DNS level tunnel - but many of the error conditions are... tcp and dns errors manifest differently through the proxy - usually 5xx's in the case of http://.. I'm actually not entirely sure what error is common on a CONNECT tunnel for https://.. plausibly you could either get a 5xx or you could get a quick 200-tunnel established followed by a fin. How does that map to NEL and mix in the same data set for server side consumption that has people connecting directly.

What about errors connecting to the proxy itself - it doesn't seem any less relevant than an error with your gateway which would already get lumped in.

[sleevi]

@igrigorik Presently, the spec says

For example, a network error report may be triggered when a fetch fails due to proxy or gateway errors, service downtime, and other types of server errors.

However, it doesn't seem like that's been addressed in the Security/Privacy considerations. For example, reporting a 407 status code for NEL (along with server-ip) seems like it would have catastrophic privacy properties, in that it would be disclosing users' proxy servers.

Would love to see greater guidance and analysis within the spec with regards to proxy-induced errors, noting the issues @mcmanus raised

[dcreager]

The spec no longer mentions proxy failures as resulting in NEL reports. The server_ip field contains the IP address of the origin server that the user is attempting to reach through the proxy; no information about the proxy itself is included in the NEL report. There is now language in the privacy section that explicitly covers that — NEL reports should not contain any information that would not be visible to the server.