Open Bug 1249058 Opened 8 years ago Updated 2 years ago

CSP Report Only prevents resources from loading when report server is slow to respond

Categories

(Core :: DOM: Security, defect)

defect

Tracking

()

People

(Reporter: bsterne, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-backlog])

In cases where there are a number of content items that violate CSP-Report-Only, and when the report server is slow to respond, additional resources are prevented from loading until the report server responds.

I believe the root of the issue is that the report requests count against the max-connections-per-server, so one way to address this issue would be to exempt the report requests from this limit.

I'm also seeing some behaviors in terms of the timing of the requests and when the content is executed that are a little unusual. I'll follow up with a test that illustrates.
Is the reporting host separate from the host(s) serving content? If it's the same host then we could easily swamp the max connections per host and start queuing network requests. Reporting should be async (and we need to verify that) but even assuming it is sending back to the same host is going to bottleneck. Steve suggested we could maybe associate a priority with network requests, and if so put CSP reports at the lowest priority (but we'd need new APIs). Wouldn't help unblock active connections, but would help prioritize web content requests in the queue as connections open up again.

If your reporting host is separate it seems unlikely that you could swamp network.http.max_connections of 256 if the reporting host is limited to network.http.max-persistent-connections-per-server of 6. That scenario would suggest that our report connections are not async as they should be. CSP shouldn't care too much if the reports don't make it -- best effort.

Is the problem limited to "report-only"? I can't imagine reporting for an enforced policy is any different. Maybe I'm misunderstanding: is the loading trouble limited to the resource that the report concerns (in which case report-only is definitely relevant, since we already wouldn't load it if the block were enforced)? Or does is it a more general bottleneck that prevents loading content that isn't otherwise affected by CSP in any way?
In trying to create a reduced testcase, I'm not sure there's an actual issue here. What I saw yesterday in a production app was a number of violation reports getting stacked up and waiting on a response, and only after the report server responded, did subsequent resource loads resume. I assumed I was hitting max-persistent-connections-per-server.

Today, I was trying to reproduce with a local testcase and was not able to cause resource loads to be waiting on the report requests. Even when I moved max connections down to 1, the requests would go out in pairs: 1 for the resource and 1 for the report. I don't think the report requests count against max connections.

I'm at a loss as to what was preventing my resources from loading earlier, and I strongly suspect it was CSPRO, but I can't prove it. I may leave this bug open another day or so to investigate further, but if I can't create a reproducible test I'll close it out. I'm certainly open to suggestions in the meantime.
Whiteboard: [domsecurity-backlog]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.