PerformanceResourceTiming transferSize getter steps does not consider cross origin resources.

[colelao]

The PerformanceResourceTiming transferSize attribute's getter steps do not account for all conditions. There are no steps for cross origin resources. In section 4.5 Cross-origin Resources, it notes that transferSize can be zero for opaque entries, which is in conflict with the getter steps previously stated.

The getter steps for the PerformanceResourceTiming transferSize should include the cross origin resource case to match with the statement in section 4.5 Cross-origin Resources. I suggest something similar to:

1. If the timing allow check algorithm fails for a cross-origin resource, then return 0.

2. If this's cache mode is "local", then return 0.

3. If this's cache mode is "validated", then return 300.

4. Return this's response body info's encoded size plus 300.

[nicjansma]

@colelao thanks for the feedback!

Agreed the existing 3 steps look like a complete enumeration of how the property getter should work:

As you say, there is section 4.5 that covers how many of the RT properties are affected by cross-origin/TAO/etc.

Of note, the third step for transferSize getter grabs the encoded size from Fetch, which I believe had set cross-origin-affected properties to 0 before (somewhere around here?).

If we were to update just the transferSize getter to make this more clear, I think we'd want to also update all of those other properties (e.g. encodedBodySize, decodedBodySize, etc) and that could be very verbose.

Maybe instead we could a small see §4.5 or something to each to make it clear, that Fetch is what is "zeroing" this data out, for each property affected?

[colelao]

Yes, I see the problem. I agree it could get too verbose. I like the addendum at the end of step 3; it calls out the exception without too much bloat. Thanks for getting back to me!

[annevk]

I don't think that solution works. Fetch returns 0 but you are adding 300. That makes it 300. If you want it to stay 0 somehow, you'll have to make the algorithm branch on something else as well.

To be clear, section 4.5 is entirely non-normative so doesn't really mean much for implementations.

cc @noamr @yoavweiss

[noamr]

I don't think that solution works. Fetch returns 0 but you are adding 300. That makes it 300. If you want it to stay 0 somehow, you'll have to make the algorithm branch on something else as well.

Yea currently the spec and implementations (at least blink) returns 300 for a non-cached cross-origin resource. The proae should reflect that.

To be clear, section 4.5 is entirely non-normative so doesn't really mean much for implementations.

cc @noamr @yoavweiss

[colelao]

Is verbosity something we should be concerned about at all then?

[annevk]

@noamr that sounds inaccurate. https://github.com/web-platform-tests/wpt/blame/master/service-workers/service-worker/resource-timing-cross-origin.https.html has been testing that transferSize is 0 for about four years and Chromium was passing that (meaning it was contradicting the specification which wants 300).

[noamr]

@noamr that sounds inaccurate. https://github.com/web-platform-tests/wpt/blame/master/service-workers/service-worker/resource-timing-cross-origin.https.html has been testing that transferSize is 0 for about four years and Chromium was passing that (meaning it was contradicting the specification which wants 300).

Ha, you're right, I was looking at the blink implementation, I'll check what's up with transferSize. Speaking of that test, I believe that webkit has now changed it in a way that it contradicts the spec... we need to resolve that.

[annevk]

@colelao is reverting in WebKit/WebKit#58246 though it's not clear to me a full revert is in order as it certainly seems wrong either way (i.e., transferSize and maybe other aspects).

[noamr]

Opened a chromium bug:, as well as a spec PR to clarify this in the prose.

[noamr]

Ok, looking at the SW and fetch specs, I think 300 is right for transferSize by current spec but I think it should be fixed.

The encodedSize is 0 for opaque responses, and the cache state is nulled in fetch for regular responses when TAO fails. However when this is a SW response, the cloned response carries the cache state with it but the fetch doesn't fail TAO so it not nulled.

I think we should amend the SW spec to always null the cache state of the cloned response, as it's not relevant for the external fetch.

[annevk]

What do you mean with nulled? The only way you will get transferSize to return less than 300 is if cache mode is "local" which doesn't seem appropriate?

[noamr]

What do you mean with nulled? The only way you will get transferSize to return less than 300 is if cache mode is "local" which doesn't seem appropriate?

Ah you're right. I was conflating between local and empty string. So 300 it is.