include 202 in ok_status_codes?

[a11ya11y]

crawler.py currently sets ok_status_codes = [200, 301, 302, 307, 308].

Some sites, notably sites hosted by shinyapps.io are inconsistently scanned by CWAC. In some cases, they let CWAC through, and in others they return a 202 status code, and we've been unable to determine the cause of the inconsistency. We thought that setting perform_header_check: false (by including these sites in /base_urls/nohead/) was the solution, but even then, sometimes the shinyapps.io sites still block CWAC and return a 202 status code.

In our latest tests, including 202 in ok_status_codes seems to allow consistent scanning of those shinyapp.io sites and no 202 codes returned.

@G-Rath Do you foresee any issues including 202 in ok_status_codes?

[G-Rath]

@a11ya11y do you have any example links you can share for this?

[a11ya11y]

@G-Rath It's all of the Shiny apps at *.shinyapps.io:

https://mbienz.shinyapps.io/labour-market-dashboard_prod/
https://mbienz.shinyapps.io/RegionalFactsheets/
https://mbienz.shinyapps.io/sector_report_prod/
https://minhealthnz.shinyapps.io/ABD_Domicile_2022Q4/
https://minhealthnz.shinyapps.io/ABD_Domicile_2023Q1/
https://minhealthnz.shinyapps.io/ABD_Domicile_2023Q2/
https://minhealthnz.shinyapps.io/ABD_PHO_2022Q4/
https://minhealthnz.shinyapps.io/ABD_PHO_2023Q2/
https://minhealthnz.shinyapps.io/ASH_by_PHO/
https://minhealthnz.shinyapps.io/ASH_district_dom/
https://minhealthnz.shinyapps.io/ED_Alcohol_Domicile/
https://minhealthnz.shinyapps.io/Inpatient_Average_Length_of_Stay/
https://minhealthnz.shinyapps.io/national-gambling-study-data-explorer/
https://minhealthnz.shinyapps.io/nz-health-survey-2014-15-srh-data-explorer/
https://minhealthnz.shinyapps.io/nz-health-survey-2015-16-tobacco-data-explorer/
https://minhealthnz.shinyapps.io/nz-health-survey-2016-17-mental-health-explorer/
https://minhealthnz.shinyapps.io/nz-health-survey-2017-20-regional-update/
https://minhealthnz.shinyapps.io/nz-health-survey-2022-23-mental-health-data-explorer/
https://minhealthnz.shinyapps.io/WhakamauaDashboard/

Sometimes they're scanned, sometimes not and returning 202. If we accept 202, they seem to be scanned reliably.

We've not noticed any negative impact of accepting 202, but are looking for a more informed opinion.

[G-Rath]

so I've tried digging into this and while there's still alot of questions, I think what this is is that shinyapps are able to "sleep" and when requested in a sleeping state they return a 202 when they're loading:

❯ curl https://minhealthnz.shinyapps.io/ABD_Domicile_2022Q4/
...
<script>
var app_url = 'https://minhealthnz.shinyapps.io/ABD_Domicile_2022Q4';
var healthcheck_endpoint = '/__health-check__/';
var started_at = new Date().getTime();
var finished_at = null;
var count = 0;
var timeout = null;
function debug(message) {
if (window.console && window.console.log) {
window.console.log(message);
}
}
function reload() {
window.location.reload(true);
}
function wait() {
// wait and try again
count += 1;
var snooze = Math.min(3000, (250 * count));
debug("Application not loaded. Retrying in " + snooze + "ms");
setTimeout(function () {
check();
}, snooze);
}
function check() {
var url = app_url + healthcheck_endpoint;
$.ajax({url: url, cache: false})
.done(function (data, textStatus, xhr) {
if (xhr.status === 200) {
// log time elapsed
finished_at = new Date().getTime();
var elapsed = finished_at - started_at;
debug("Application loaded in " + elapsed + "ms (" + count + " checks). Reloading.");
if (timeout != null) {
clearTimeout(timeout);
}
reload();
} else {
wait();
}
})
.fail(function() {
wait();
});
}
$(document).ready(function () {
debug("Waiting for application to load ...");
check();
// reload regardless of success after 10 seconds
timeout = setTimeout(function () {
debug("Application failed to load after 10 seconds. Reloading.");
reload();
}, 10000);
});
</script>

<!-- block scripts -->
</html>

~ via  v20.19.0 via 🐍 v3.10.12 via 💎
❯ curl-headers-only https://minhealthnz.shinyapps.io/ASH_by_PHO/
HTTP/2 202
date: Thu, 25 Sep 2025 03:43:22 GMT
content-type: text/html; charset=UTF-8
content-length: 4445
server: openresty
cache-control: no-store, no-cache, must-revalidate, max-age=0

After they've been woken up requests will then return the actual page upfront - that means they can probably be somewhat reliably audited, but we might need extra handling to ensure the page has been properly loaded before auditing; then again, you could also argue that this delay in loading is an issue anyway because it means pages perform rather poorly 🤔