Serve the manifest at the path and shape section 11.1 fixes #61
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/manifest-for-the-spec"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The firmware repository took the update manifest into the specification as section 11.1, after we had defined our own. The specification decides, and a node fetching from us today failed at the first request.
The manifest moves to the fixed
/firmware/manifest.json, andimagesbecomes an object keyed by0xand the node type in two hex digits rather than an array. Each entry carriespath,sizeandsha256. Both answers already carried aContent-Length; the tests now pin it, since a node cannot check an image againstsizeor report a percentage without one.environment,node_typeandversionare dropped. A node ignores members it does not know, so they could have stayed, but each is already readable from the key or the image path, and a second copy of a fact in a document two implementations read is where drift starts.Image paths stay ours — the specification fixes where the manifest lives and what it says, not where the images it names sit — so the
/firmware/<environment>/<version>/<file>tree is unchanged. So is the traversal defence: a request path is still looked up against what the manifest advertised rather than joined onto the cache root.The module docstring said the manifest was ours to define. That was true when written, and the docstring now says it is section 11.1's.
CCS-UHA-13.
The manifest shape, the key format, the fixed path and the trimmed members all match spec section 11.1, and the traversal lookup is untouched. Three things on the tests and one comment.
tests/test_node_file_server.py:223—manifest.headers["Content-Length"] == str(len(manifest.body))cannot fail on a wrong length.http.clientreads exactlyContent-Lengthbytes, so the body's length is defined by the header being asserted. Sendinglen(body) - 1for the JSON response only leaves all 20 tests green. Pin it against something independent of the header:assert manifest.body.endswith(b"}\n")catches the truncation, or compare with the serialised manifest's length. The image half of the test is fine —str(len(LIGHTS))is an independent value.tests/test_node_file_server.py:180-184— thestr.lower/str.upperloop exercisesint(), not the server. There.fullmatchabove already pins lowercase two-digit keys, soint(key.upper(), 16)can only succeed. Drop the loop; what remains then duplicatestest_the_manifest_keys_every_node_type_the_cache_holdsdirectly above, so the two tests want folding into one. "Read in either case" is a constraint on the node reading the manifest, not on this server writing it, so there is nothing here to test beyond the regex.updater/file_server.py:9-10— "They were ours when nothing in the specification covered this, and that is no longer true" is a note about this change rather than about the code. It belongs in the commit message; the first sentence carries the fact a future reader needs.Taken, all three, in
78f838d.endswith(b"}\n")), with the image half comparing against the length we know independently. Mutatingrespond()to sendlen(body) - 1now fails the test.test_the_manifest_keys_every_node_type_by_its_hex. The either-case loop has gone: reading a key in either case binds the node, and we are the writer, so the only thing we can pin is the form we emit.All three taken. The length test now fails both ways it should — a short
Content-Lengthon the JSON response, and the header dropped altogether. Nothing outstanding.