edfcore 0.4.467 → 0.4.469
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +35 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
|
|
|
109
109
|
readonly reserved: 224;
|
|
110
110
|
};
|
|
111
111
|
/** Published package version. Kept in sync with package.json by a test. */
|
|
112
|
-
export declare const VERSION = "0.4.
|
|
112
|
+
export declare const VERSION = "0.4.469";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,41 @@ alone does not tell you whether you were affected.
|
|
|
6
6
|
edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
|
|
7
7
|
defect; those are called out below.
|
|
8
8
|
|
|
9
|
+
## 0.4.469
|
|
10
|
+
|
|
11
|
+
- **Added** the cases where a 206's `Content-Range` cannot be parsed at all. edfcore checks that
|
|
12
|
+
header against the range it asked for, because `assertExactRead` is a length guard and cannot
|
|
13
|
+
see a right-sized body taken from the wrong offset — but `rangeFromContentRange` returns
|
|
14
|
+
`undefined` for anything outside `bytes <first>-<last>/`, and `undefined` means "no usable
|
|
15
|
+
claim", not "the claim was wrong".
|
|
16
|
+
- Every existing case supplied a well-formed header or none at all, so the two `return undefined`
|
|
17
|
+
lines in the middle had never run. Turning either into a refusal would reject reads that are
|
|
18
|
+
fine, from servers that are behaving within RFC 7233.
|
|
19
|
+
- Four shapes reach them and all four occur: a range unit that is not `bytes`, the unsatisfiable
|
|
20
|
+
`bytes */total` form, a header truncated before the total, and byte positions past 2^53 from a
|
|
21
|
+
proxy in front of an object store that counts in something else. A `FetchLike` double answering
|
|
22
|
+
every header with `null` is the fifth, and is the reason the rule is written this way.
|
|
23
|
+
- The non-vacuous half is asserted on both sides of them: a header that DOES parse and names a
|
|
24
|
+
different part of the resource is still refused, and a short body behind an unreadable header is
|
|
25
|
+
still caught by length. "Unreadable" has not become "unchecked".
|
|
26
|
+
|
|
27
|
+
## 0.4.468
|
|
28
|
+
|
|
29
|
+
- **Added** tests for the half of `redactDiagnostic` that had never been asked: what happens to a
|
|
30
|
+
diagnostic on a withheld field that carried no `raw` or no `actual`. Both substitutions are
|
|
31
|
+
conditional, and making either unconditional left the suite green.
|
|
32
|
+
- The consequence is the 0.3.31 failure with its sign flipped. `raw: "[redacted]"` on a diagnostic
|
|
33
|
+
that never held the bytes makes `formatDiagnostics` print a `raw:` line under it, so a reader
|
|
34
|
+
auditing a report for what the tool held back finds evidence of patient text where there was
|
|
35
|
+
none. Output that looks redacted is worse than an obvious leak in both directions.
|
|
36
|
+
- Also pinned: `expected` survives redaction. It is the grammar the field should have followed,
|
|
37
|
+
not a value read out of the file, and substituting it removes the only part of the line that
|
|
38
|
+
says what to do. And `actual` alone is enough to clear the message, which matters because a
|
|
39
|
+
diagnostic with no `raw` has no other spelling of the value to substitute by.
|
|
40
|
+
- The diagnostics are written out rather than provoked from a file: `formatDiagnostics` is public
|
|
41
|
+
and takes any `EdfDiagnostic[]`, every parser-built identification diagnostic happens to carry
|
|
42
|
+
both fields, and the contract being pinned is the function's rather than one file's.
|
|
43
|
+
|
|
9
44
|
## 0.4.467
|
|
10
45
|
|
|
11
46
|
- **Added** the test for the third arm of `DIGITAL_RANGE_EXCEEDS_FORMAT`'s advice clause, added in
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED