You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 6, 2022. It is now read-only.
Based on a cursory scan through the current code in http_parser.c one possible approach immediately jumps out at me: handle it similar to the way you handle header field names. That is, mark the start of the method and run through your method recognition logic. If you detect one of the methods you know, fantastic, if it's not one that you recognize, set parser->method to some generic "unknown" and do a CALLBACK_DATA(...). If the callback returns an error, then the method is not recognized... throw your error and move on. If the callback returns ok, beautiful, move on. As part of this, add in a check to verify each character is a token and you should be good without any real noticeable impact on performance.
Like I said, that's just one approach that stood out given a first pass through the code. The performance concerns for parsing arbitrary http header names (which are also tokens of unbounded length) are pretty much identical to any concerns you may have about the request method so using a similar approach would seem to make sense.
The text was updated successfully, but these errors were encountered:
nodejs/node-v0.x-archive#6078 (comment)
Based on a cursory scan through the current code in http_parser.c one possible approach immediately jumps out at me: handle it similar to the way you handle header field names. That is, mark the start of the method and run through your method recognition logic. If you detect one of the methods you know, fantastic, if it's not one that you recognize, set parser->method to some generic "unknown" and do a CALLBACK_DATA(...). If the callback returns an error, then the method is not recognized... throw your error and move on. If the callback returns ok, beautiful, move on. As part of this, add in a check to verify each character is a token and you should be good without any real noticeable impact on performance.
Like I said, that's just one approach that stood out given a first pass through the code. The performance concerns for parsing arbitrary http header names (which are also tokens of unbounded length) are pretty much identical to any concerns you may have about the request method so using a similar approach would seem to make sense.
The text was updated successfully, but these errors were encountered: