I added this because in PhpStorm because otherwise there is a warning:

The reason the IDE doesn't know the export is used is because it is used in PHP and via a dynamic export. See also https://stackoverflow.com/questions/54687009/export-default-unused-in-webstorm

This noinspection annotation is used in Gutenberg once as well: https://github.com/WordPress/gutenberg/blob/8b88ada2fd675509bf0c39a55c23a75cc67987cb/packages/components/src/mobile/link-settings/test/edit.native.js#L1

Per above, this should be conditional based on gzdecodeAvailable.

I removed this check from od_handle_rest_request as we can compress the URL metrics. However, in cases where gzdecode is unavailable, should we reintroduce this check in od_handle_rest_request, conditioned upon the availability of gzdecode?

Additionally, if a malicious user sends data with application/json content type and gzdecode is available, there is currently no check enforcing an upper limit on the size of the URL metrics.

Oh yes, good points!

Should we add a limit of 1MB for URL metrics? I am not sure about the what should be the limit.

I wonder as well, when gzdecode() is available, what happens if I try (maliciously) submitting a URL Metric which has 1,000,000 instances of the same element? Given that compression will likely be very effective in this case with the duplication, will it result in something extremely large being submitted when decompressed? If so, should we have some fallback size constraint for a decompressed URL Metric?

(I think we were thinking along the same lines here and commented at the same time.)

Yes, let's maybe introduce a new function that returns the maximum byte size for a URL Metric serialized to JSON. The function's return value can be filtered, but defaulting to MB_IN_BYTES seems good to me. This should perhaps get exported to the client so that the pre-compressed JSON size can be checked to see if it is too big so the client will skip sending it in that case.

Just a thought—should we compress the URL metrics before storing them in the database? Would using gzdecode cause performance issues, since we'll need to decompress the data on every request to the optimized page? Compressing the metrics could allow us to store larger URL metric data, but I'm not sure if any real-world scenario would generate more than 1 MB of URL metrics.

I don't think we need to compress in the DB, no. That would be an over-optimization and could negatively impact performance at runtime with having to decompress. Storage is cheap. What is expensive is network bandwidth, especially with the limitations of the beacon size. So that's what we want to optimize for.

I tried submitting a URL Metric with various numbers of copies of the first element completely populating the elements. I was able to get up to 18,000 identical elements being copied before going over the 64 KiB limit with compression. Before this URL Metric was compressed, it was a total of 10,584,362 bytes (10.6 MB). So 1,800 elements is roughly 1 MB. This seems like a reasonable limit to impose.

I tried doing something silly and visit every single tag:

add_action( 'od_register_tag_visitors', function ( OD_Tag_Visitor_Registry $registry ) {
	$registry->register( 'all', '__return_true' );
} );

On a post with 1,000 Image blocks, this resulted in 2,198 elements in the URL Metric. The uncompressed size of the URL Metric is 1,068,353 bytes (about 1 MB), with the compressed size being 33,047 bytes (52% of 64 KiB limit). So indeed, I think 1 MB is probably far larger than any URL Metric will naturally be, so it's a safe upper bound for what should be allowed.

I just had a thought that perhaps an Accept response header should be added for this endpoint. This apparently isn't needed because I don't see Accept: application/json being served anywhere now in REST API responses. Just something to think about.

I looked at this in PhpStorm and I noticed an error:

So then I added it to require in c59c3ed, but then I wondered what core does with this function. I found this:

https://github.com/WordPress/wordpress-develop/blob/d5a3a140ee0e459acedd3c182274a2b14adc5bdb/src/wp-includes/class-wp-http-encoding.php#L72-L78

Note that core checks if the function exists. I think what we'll have to do is do the same, and that od_get_detection_script() we'll need to add a new param which is exported to the client like gzdecodeAvailable which contains the value of function_exists( 'gzdecode' ). This can then be used to conditionally compress the URL Metric data before sending it to the REST API.

We should use the function in the same way it is being used in core, perhaps even with the error suppression.

Added logic for handling gzdecode() availability in af1d1dc