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

feat: http parse max lengths #106

Merged
merged 3 commits into from
Oct 28, 2024
Merged

feat: http parse max lengths #106

merged 3 commits into from
Oct 28, 2024

Conversation

lonerapier
Copy link
Collaborator

closes #105
closes #101


  • adds MAX_* length params, and add use *Padded templates to match
  • add step by step UT for HTTP NIVC template

Copy link
Contributor

@Autoparallel Autoparallel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Changes are simple enough.

I think the GreaterThan template has me worried a little bit because it seems gameable. So let's think about the constraints there and if we are still concerned, we make an issue to address it down the road.

@@ -48,9 +49,10 @@ template LockHeader(DATA_BYTES, MAX_STACK_HEIGHT, MAX_HEADER_NAME_LENGTH, MAX_HE
signal headerFieldNameValueMatch <== HeaderFieldNameValueMatchPadded(DATA_BYTES, MAX_HEADER_NAME_LENGTH, MAX_HEADER_VALUE_LENGTH)(data, header, headerNameLength, value, headerValueLength, headerNameLocation);
headerFieldNameValueMatch === 1;

// parser state should be parsing header
// parser state should be parsing header upto 2^10 max headers
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Big upper bound for sure, but if someone does pick something larger than this, what happens with the GreaterThan(10) template? Does it fail to prove? Or do we get some incorrect value out?

Just want to make sure this is properly constrained. If not, it's okay for now, but we should make an issue.

Copy link
Collaborator Author

@lonerapier lonerapier Oct 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it fails to run, there's an assert in LessThan template that checks input - 2^10 is 10 bit valid number

@@ -138,7 +138,7 @@ describe("HTTP :: Codegen :: Response", async () => {

const headers = getHeaders(lockData);

const params = [input.length, parseInt(http.headers["Content-Length".toLowerCase()]), lockData.version.length, lockData.status.length, lockData.message.length];
const params = [input.length, parseInt(http.headers["Content-Length"]), lockData.version.length, lockData.status.length, lockData.message.length];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh good, we dropped this case requirement here?

Copy link
Collaborator Author

@lonerapier lonerapier Oct 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it can be a debatable decision. IDK why I added this in the first place, so my reasoning to remove this is to perform an exact match on headers, because previously it was lower case.

and i've seen in multiple examples according to RFC header match should be case insensitive.

So, we have to add support for it down the line. created an issue: #107

circuits/test/http/nivc/lock_header.test.ts Show resolved Hide resolved
@lonerapier lonerapier merged commit fab6430 into main Oct 28, 2024
4 checks passed
@lonerapier lonerapier deleted the feat/max-lengths branch October 28, 2024 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants