The DAP4 specification says how to properly handle checksums, but this was improperly implemented in netcdf-java. This PR makes some changes to handle checksums.
WARNING: The merging of this PR needs to be synchronized with the following netcdf-java PR: XXXX.
So after both PRs are reviewed and approved, both need to be merged one right after the other.
Note also that their are still unresolved ambiguities about checksums in the DAP4 specification that need resolution. See here for example. So at the moment, accessing non-thredds servers via DAP4 requires special treatment.
Properly compute and apply checksums in the DAP and DMR responses.
Fix tests that require the _DAP4_Checksum_CRC32 attribute.
Non-DAP4 Changes
The only controversial change is that to ucar.ma2.Index, about line 573. The change is as follows:
int prefixrank = (hasvlen ? rank: rank - 1);
to
int prefixrank = (hasvlen ? rank - 1 : rank);
The original line is clearly an error under the assumption that "*" dimensions are always the last dimension for an array. I was worried about this causing follow-on failures, but not surprisingly because vlen is so screwed up, no follow-on failures have appeared.
DennisHeimbigner
commented
1 year ago
Description of Changes
The DAP4 specification says how to properly handle checksums, but this was improperly implemented in netcdf-java. This PR makes some changes to handle checksums.
WARNING: The merging of this PR needs to be synchronized with the following netcdf-java PR: XXXX. So after both PRs are reviewed and approved, both need to be merged one right after the other.
Note also that their are still unresolved ambiguities about checksums in the DAP4 specification that need resolution. See here for example. So at the moment, accessing non-thredds servers via DAP4 requires special treatment.
PR Checklist
DAP4 Changes
Non-DAP4 Changes
The only controversial change is that to ucar.ma2.Index, about line 573. The change is as follows:
The original line is clearly an error under the assumption that "*" dimensions are always the last dimension for an array. I was worried about this causing follow-on failures, but not surprisingly because vlen is so screwed up, no follow-on failures have appeared.