Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEP-0007 - limited size header #52

Open
martinheidegger opened this issue Dec 12, 2018 · 1 comment
Open

DEP-0007 - limited size header #52

martinheidegger opened this issue Dec 12, 2018 · 1 comment

Comments

@martinheidegger
Copy link
Contributor

martinheidegger commented Dec 12, 2018

When reading DEP-0007 I noticed that the dataStructureType can be any string.
(of varint data-size: big) However: most file signatures are fixed in size, which makes me wonder if it wouldn't be a good idea to amend a limit of "how big the size can be" in order to prevent the downloading of a lot of data before checking if the data even fits the structure.

@bnewbold
Copy link
Contributor

bnewbold commented Feb 1, 2019

As a weakly held, somewhat subjective opinion, I think we should err on the side of "keeping it simple" by not specifying maximum lengths for every string and field at this level of the format/protocol (AKA, fields inside protobuf). We could add a statement like "use good judgement".

A couple unstructured thoughts:

  • when reading from disk, there are already fixed-size headers with metadata about the format (just not the hypercore content type)
  • if we wanted a limit, it would probably make more sense to apply it to the entire protobuf message, instead of to individual fields inside it. AFAIK there's an implied size limit of 2GB to protobuf messages in many implementations, and in hypercore we recommend message sizes under a megabyte (or 10? reference needed)
  • I might feel differently if protobuf schemas themselves allowed setting size limits on fields (which IIRC they do not). As it doesn't, every implementation would need to implement additional verification/validation, which is extra work and complexity and needs testing.
  • to me at least, the closer analog to dataStructureType is MIME types, especially when embedded in HTTP headers as Content-Type, which as far as I know has no maximum length.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants