c9s / h3 Goto Github PK
View Code? Open in Web Editor NEWThe Fast HTTP header parser library
The Fast HTTP header parser library
-- Configuring done
CMake Error at tests/CMakeLists.txt:15 (add_executable):
Cannot find source file:
bench/bench.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
CMake Error: CMake can not determine linker language for target: bench_h3
CMake Error: Cannot determine link language for target "bench_h3".
-- Generating done
-- Build files have been written to: /home/abaumann/h3
Should cmake be used or make -f Makefile.dist
?
I would like to point out that an identifier like "_HeaderField
" does not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?
I didn't find any API which can get the packet cookies?why?
During the compilation of the h3 parsing, some warnings occur.
make -f Makefile.dist
src/request_header.c: In function ‘h3_request_header_parse’:
src/request_header.c:86:5: warning: statement with no effect [-Wunused-value]
src/request_header.c:116:9: warning: statement with no effect [-Wunused-value]
This is caused by the usage of the macro to determine if it is a CR-LF iscrlf(p); p+=2;
This macro is defined in src/scanner.h:35
as #define iscrlf(p) (*p == '\r' && *(p + 1) == '\n')
I am not familiar enough with the code and the various RFC's to asses this situtation.
I can immagine that either:
if ( iscrlf( p ) ) { p += 2; }
p += 2;
Please advice what to do for both line 86
and 116
.
Going through this good work. It is very nice to see this effort. Trying to create benchmark for this - but the memory allocations inside the h3_request_header_parse() are killer.
Just couple of suggestions to consider to improve performance:
Use intrusive mechanism: that is, instead of creating memory inside, accept the header-fields as an input array and try to fill them. Personally I would not like it, because it would demand the caller to know the number of header fields to allocate the array before-hand.
But, one technique could be: let the caller pass a header array (with whatever size he thinks as reasonable) and the h3_request_header_parse() method parses and fills only as many as the available fields (sent by caller). If there are more fields pending, but the input array cannot hold them, then the parser just returns the no. of bytes consumed, so that the caller can compare it with size of input and call the h3_request_header_parse() in a loop till all fields are parsed. This would require returning to caller in a reasonable state (so that the parser can resume later correctly when called with brand new field array).
Use call-back mechanism: This way, the parser would never need to worry about memory at all. For example, the h3_request_header_parse() method will contain a local stack based header-field that gets filled inside the loop and just before the next iteration, make the call-back() with the filled the filed as argument to it, so that caller will do whatever he wants to do with that particular field. May be he will aggregate them into array or just scan and dump it.
The call-back could also be used by the caller to tell if the parser should proceed further or end by returning true/false.
For example, the prototype of call-back could be: bool (*lpfnCallback)(HeaderField&);
Then, the prototype of h3_request_header_parse() would be:
int h3_request_header_parse(lpfnCallback fn, const char *body, int bodyLength)
{
do
{
HeaderField field;
// fill the filed here
if(false == fn(field)) break;
}while(notend(p));
}
Encountering this while running the test application on Windows. (There is some garbage characters loading at the end of chrome test file on windows with fread()).
Right now, the h3_request_header_parse() method is doing a sanity check after every 'while' only for 'if (iscrlf(p)) return -1'
It should also include the test for end of string apart from 'iscrlf()'. For example, it should be:
if (end(p) || iscrlf(p)) return -1;
Also, in such case the newly allocated 'HeaderField *field = h3_header_field_new();' at the start of loop would go waste. So, it is suggested to use a local stack variable at the start of loop to hold the values parsed in that iteration and allocate the field at the end of loop (after everything completed successfully) and then memcpy the local stack variable onto the heap allocated one. That way, only successfully parsed fields would be allocated memory and any failures would just get away with stack-based field.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.