CLDR-16900 Avoid 304 Not Modified; instead use boolean json.unchanged

[btangmu]

-Standard usage of 304 would involve adding headers and getting cached json from browser; this is more efficient

-Also restore and revise tools/cldr-apps/js/test/run.sh for convenience (CLDR-17481)

CLDR-16900

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[macchiati]

I looked this over but @srl295 should be the one to review.

[srl295]

-Standard usage of 304 would involve adding headers and getting cached json from browser; this is more efficient

I don't follow this.. which headers would need to be added?

Approving so we can move it forward, just asking

[btangmu]

I don't follow this.. which headers would need to be added?

@srl295 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304 says "This response code is sent when the request is a conditional GET or HEAD request with an [If-None-Match] or an [If-Modified-Since] header and the condition evaluates to false."

It seems that under those conditions, the browser (receiving 304) may deliver a cached response to the client application (which then receives 200) -- it's transparent to the client app, assuming the browser has the cached response. See https://www.hostinger.com/tutorials/304-status-code

I'm not sure but returning 304 when the request lacks such headers might be unconventional or worse...

[srl295]

I don't follow this.. which headers would need to be added?

@srl295 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304 says "This response code is sent when the request is a conditional GET or HEAD request with an [If-None-Match] or an [If-Modified-Since] header and the condition evaluates to false."

It seems that under those conditions, the browser (receiving 304) may deliver a cached response to the client application (which then receives 200) -- it's transparent to the client app, assuming the browser has the cached response. See https://www.hostinger.com/tutorials/304-status-code

I'm not sure but returning 304 when the request lacks such headers might be unconventional or worse...

that does make sense.

we could use the if-modified-since field and expiry times - and use a date instead of an announcement number, and the benefit is that the browser would do the caching for us, even between multiple windows querying the same server.. but you're right, it would bring other headaches.

Another possibility which I've used productively is http://http.cat/204 204 no content but that apparently is cacheable by default also.

[btangmu]

For future reference: https://dev.to/didof/the-art-of-efficient-web-browsing-public-resources-27hl