-
Notifications
You must be signed in to change notification settings - Fork 1
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
Conversation
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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]; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
closes #105
closes #101
MAX_*
length params, and add use*Padded
templates to match