Distinguish "Not-Allowed" from zero value entries about resource-timing HOT 10 CLOSED

The introduction of integer values (transferSize, encodedBodySize and decodedBodySize) means that we can no longer use 0 as a value indicating that a 3rd-party origin did not pass the timing-allow check.

I think this still works.. e.g. if domainLookupStart is zero then you known that TAO permission bits are missing, regardless of what *Size attributes report.

from resource-timing.

@yoavweiss bump. Can we close this?

from resource-timing.

While I agree that developers could conclude with high probability the absence of TAO and therefore deduce what a 0 value means for transferSize et al, it would be significantly simpler and less hacky if we'd define that a lack of TAO results in negative transferSize (e.g. -1 which seems to be a popular choice in such cases). Since these sizes are unsigned in their nature, there's little risk of confusion there.

Do you see any problems with that approach? If not, I'll be happy to PR that spec change.

from resource-timing.

Hmm, I'm not convinced: we don't do this for any other attributes, they all return zero; it seems rather hacky to overload what is, effectively, a bytesize attribute with completely different meaning. I'd consider a negative value on time or size a bug.

from resource-timing.

OK, then maybe that's not the right approach.

Still, I think that asking devs to conclude TAO state from other values is not great dev ergonomics. Maybe we should expose TAO state directly?

from resource-timing.

Hmm, is that really necessary? I don't think introduction of {transfer,decodedBody,encodedBody}Size actually changed anything, as far as ergonomics is concerned...

The developer can inspect responseStart: the only time it reports 0 is when TAO opt-in is necessary and missing. You don't need to check anything else; nothing has changed in this respect.

What is different now, is that if TAO opt-in is present, the developer can now check transferSize: if the value is 0, then they know that the resource was served from cache. So, if the developer wants to know if a particular resource was served from cache:

performance.getEntriesByType('resource').forEach(r => { 
 status = ""
 if (r.responseStart == 0) { status = "Unknown, TAO opt-in is missing" }
 else { 
  if (r.transferSize == 0) { status = "Served from HTTP cache" }
  else { status = "Network request was made" }
 }
 console.log(r.name + ": " + status)
})

from resource-timing.

I think we agree that exposing the TAO state explicitly won't help solving new use cases.

I argue that patterns like var isTAOServed = !r.responseStart; are bad ergonomics and hacky. This is not something new, but it is something we can fix.

OTOH, I don't feel that strongly about it, so if you disagree, feel free to close.

from resource-timing.

I argue that patterns like var isTAOServed = !r.responseStart; are bad ergonomics and hacky. This is not something new, but it is something we can fix.

Fair enough. Personally, I don't consider this to be a big deal and I've not heard developers complain about it either. As such, I'm inclined to punt on this... That said, would love to hear @plehegar and @toddreifsteck's thoughts.

from resource-timing.

bump

@plehegar @toddreifsteck any thoughts?

from resource-timing.

Discussed on the call today: closing, we can revisit in the future if there is high(er) demand for it. In the meantime, you can get this behavior via example #42 (comment).

from resource-timing.