The nodejs source credits [0] as inspiration. It seems that nginx actually does something like that: first, it switches on the length of the verb, then it tries to compare the string (using the ngx_str6cmp() and similar macros) to the ones it knows how to handle.
When the length of verb is 4, it checks if the second character is 'O' before trying the full string comparisons, probably because there are 4 possibilities with it (POST, COPY, MOVE, LOCK) vs only one without (HEAD).
It starts at line 180.
That being said, in nginx case, it's a preliminary check, just to avoid doing some full string comparisons in a very specific case. On the other hand, the nodejs directly does a 'parser->method = HTTP_CONNECT' after checking one character. It seems like it actually checks the other characters afterwards in some cases, but this affectation is quite misleading.
I'm not an expert, but I don't think you can do pure bit checks in a modern CPU. It likely does comparisons of char in a single hardware instruction anyway.
Actually, if you look at the nginx source I linked, the comparisons of the full strings are hidden behind macros because they do the opposite: they group characters 4 by 4, and do 32bit int comparisons as much as possible.
an immediate value stored in an instruction would double performance over an l1 data cache reference... but this is stated just to mock people on this thread who want 'almost' machine level logic to match robust user land permutations.
When the length of verb is 4, it checks if the second character is 'O' before trying the full string comparisons, probably because there are 4 possibilities with it (POST, COPY, MOVE, LOCK) vs only one without (HEAD).
It starts at line 180.
That being said, in nginx case, it's a preliminary check, just to avoid doing some full string comparisons in a very specific case. On the other hand, the nodejs directly does a 'parser->method = HTTP_CONNECT' after checking one character. It seems like it actually checks the other characters afterwards in some cases, but this affectation is quite misleading.
[0] http://hg.nginx.org/nginx/file/abf7813b927e/src/http/ngx_htt...