[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6438":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":4,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":16,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":21,"defaultBranch":22,"hasWiki":21,"hasPages":21,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":15,"starSnapshotCount":15,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},6438,"http-parser","nodejs\u002Fhttp-parser","nodejs","http request\u002Fresponse parser for c","",null,"C",6444,1523,41,0,1,8,40.55,"MIT License",true,false,"main",[24,7],"node","2026-06-12 02:01:24","HTTP Parser\n===========\n\nhttp-parser is [**not** actively maintained](https:\u002F\u002Fgithub.com\u002Fnodejs\u002Fhttp-parser\u002Fissues\u002F522).\nNew projects and projects looking to migrate should consider [llhttp](https:\u002F\u002Fgithub.com\u002Fnodejs\u002Fllhttp).\n\n[![Build Status](https:\u002F\u002Fapi.travis-ci.org\u002Fnodejs\u002Fhttp-parser.svg?branch=master)](https:\u002F\u002Ftravis-ci.org\u002Fnodejs\u002Fhttp-parser)\n\nThis is a parser for HTTP messages written in C. It parses both requests and\nresponses. The parser is designed to be used in performance HTTP\napplications. It does not make any syscalls nor allocations, it does not\nbuffer data, it can be interrupted at anytime. Depending on your\narchitecture, it only requires about 40 bytes of data per message\nstream (in a web server that is per connection).\n\nFeatures:\n\n  * No dependencies\n  * Handles persistent streams (keep-alive).\n  * Decodes chunked encoding.\n  * Upgrade support\n  * Defends against buffer overflow attacks.\n\nThe parser extracts the following information from HTTP messages:\n\n  * Header fields and values\n  * Content-Length\n  * Request method\n  * Response status code\n  * Transfer-Encoding\n  * HTTP version\n  * Request URL\n  * Message body\n\n\nUsage\n-----\n\nOne `http_parser` object is used per TCP connection. Initialize the struct\nusing `http_parser_init()` and set the callbacks. That might look something\nlike this for a request parser:\n```c\nhttp_parser_settings settings;\nsettings.on_url = my_url_callback;\nsettings.on_header_field = my_header_field_callback;\n\u002F* ... *\u002F\n\nhttp_parser *parser = malloc(sizeof(http_parser));\nhttp_parser_init(parser, HTTP_REQUEST);\nparser->data = my_socket;\n```\n\nWhen data is received on the socket execute the parser and check for errors.\n\n```c\nsize_t len = 80*1024, nparsed;\nchar buf[len];\nssize_t recved;\n\nrecved = recv(fd, buf, len, 0);\n\nif (recved \u003C 0) {\n  \u002F* Handle error. *\u002F\n}\n\n\u002F* Start up \u002F continue the parser.\n * Note we pass recved==0 to signal that EOF has been received.\n *\u002F\nnparsed = http_parser_execute(parser, &settings, buf, recved);\n\nif (parser->upgrade) {\n  \u002F* handle new protocol *\u002F\n} else if (nparsed != recved) {\n  \u002F* Handle error. Usually just close the connection. *\u002F\n}\n```\n\n`http_parser` needs to know where the end of the stream is. For example, sometimes\nservers send responses without Content-Length and expect the client to\nconsume input (for the body) until EOF. To tell `http_parser` about EOF, give\n`0` as the fourth parameter to `http_parser_execute()`. Callbacks and errors\ncan still be encountered during an EOF, so one must still be prepared\nto receive them.\n\nScalar valued message information such as `status_code`, `method`, and the\nHTTP version are stored in the parser structure. This data is only\ntemporally stored in `http_parser` and gets reset on each new message. If\nthis information is needed later, copy it out of the structure during the\n`headers_complete` callback.\n\nThe parser decodes the transfer-encoding for both requests and responses\ntransparently. That is, a chunked encoding is decoded before being sent to\nthe on_body callback.\n\n\nThe Special Problem of Upgrade\n------------------------------\n\n`http_parser` supports upgrading the connection to a different protocol. An\nincreasingly common example of this is the WebSocket protocol which sends\na request like\n\n        GET \u002Fdemo HTTP\u002F1.1\n        Upgrade: WebSocket\n        Connection: Upgrade\n        Host: example.com\n        Origin: http:\u002F\u002Fexample.com\n        WebSocket-Protocol: sample\n\nfollowed by non-HTTP data.\n\n(See [RFC6455](https:\u002F\u002Ftools.ietf.org\u002Fhtml\u002Frfc6455) for more information the\nWebSocket protocol.)\n\nTo support this, the parser will treat this as a normal HTTP message without a\nbody, issuing both on_headers_complete and on_message_complete callbacks. However\nhttp_parser_execute() will stop parsing at the end of the headers and return.\n\nThe user is expected to check if `parser->upgrade` has been set to 1 after\n`http_parser_execute()` returns. Non-HTTP data begins at the buffer supplied\noffset by the return value of `http_parser_execute()`.\n\n\nCallbacks\n---------\n\nDuring the `http_parser_execute()` call, the callbacks set in\n`http_parser_settings` will be executed. The parser maintains state and\nnever looks behind, so buffering the data is not necessary. If you need to\nsave certain data for later usage, you can do that from the callbacks.\n\nThere are two types of callbacks:\n\n* notification `typedef int (*http_cb) (http_parser*);`\n    Callbacks: on_message_begin, on_headers_complete, on_message_complete.\n* data `typedef int (*http_data_cb) (http_parser*, const char *at, size_t length);`\n    Callbacks: (requests only) on_url,\n               (common) on_header_field, on_header_value, on_body;\n\nCallbacks must return 0 on success. Returning a non-zero value indicates\nerror to the parser, making it exit immediately.\n\nFor cases where it is necessary to pass local information to\u002Ffrom a callback,\nthe `http_parser` object's `data` field can be used.\nAn example of such a case is when using threads to handle a socket connection,\nparse a request, and then give a response over that socket. By instantiation\nof a thread-local struct containing relevant data (e.g. accepted socket,\nallocated memory for callbacks to write into, etc), a parser's callbacks are\nable to communicate data between the scope of the thread and the scope of the\ncallback in a threadsafe manner. This allows `http_parser` to be used in\nmulti-threaded contexts.\n\nExample:\n```c\n typedef struct {\n  socket_t sock;\n  void* buffer;\n  int buf_len;\n } custom_data_t;\n\n\nint my_url_callback(http_parser* parser, const char *at, size_t length) {\n  \u002F* access to thread local custom_data_t struct.\n  Use this access save parsed data for later use into thread local\n  buffer, or communicate over socket\n  *\u002F\n  parser->data;\n  ...\n  return 0;\n}\n\n...\n\nvoid http_parser_thread(socket_t sock) {\n int nparsed = 0;\n \u002F* allocate memory for user data *\u002F\n custom_data_t *my_data = malloc(sizeof(custom_data_t));\n\n \u002F* some information for use by callbacks.\n * achieves thread -> callback information flow *\u002F\n my_data->sock = sock;\n\n \u002F* instantiate a thread-local parser *\u002F\n http_parser *parser = malloc(sizeof(http_parser));\n http_parser_init(parser, HTTP_REQUEST); \u002F* initialise parser *\u002F\n \u002F* this custom data reference is accessible through the reference to the\n parser supplied to callback functions *\u002F\n parser->data = my_data;\n\n http_parser_settings settings; \u002F* set up callbacks *\u002F\n settings.on_url = my_url_callback;\n\n \u002F* execute parser *\u002F\n nparsed = http_parser_execute(parser, &settings, buf, recved);\n\n ...\n \u002F* parsed information copied from callback.\n can now perform action on data copied into thread-local memory from callbacks.\n achieves callback -> thread information flow *\u002F\n my_data->buffer;\n ...\n}\n\n```\n\nIn case you parse HTTP message in chunks (i.e. `read()` request line\nfrom socket, parse, read half headers, parse, etc) your data callbacks\nmay be called more than once. `http_parser` guarantees that data pointer is only\nvalid for the lifetime of callback. You can also `read()` into a heap allocated\nbuffer to avoid copying memory around if this fits your application.\n\nReading headers may be a tricky task if you read\u002Fparse headers partially.\nBasically, you need to remember whether last header callback was field or value\nand apply the following logic:\n\n    (on_header_field and on_header_value shortened to on_h_*)\n     ------------------------ ------------ --------------------------------------------\n    | State (prev. callback) | Callback   | Description\u002Faction                         |\n     ------------------------ ------------ --------------------------------------------\n    | nothing (first call)   | on_h_field | Allocate new buffer and copy callback data |\n    |                        |            | into it                                    |\n     ------------------------ ------------ --------------------------------------------\n    | value                  | on_h_field | New header started.                        |\n    |                        |            | Copy current name,value buffers to headers |\n    |                        |            | list and allocate new buffer for new name  |\n     ------------------------ ------------ --------------------------------------------\n    | field                  | on_h_field | Previous name continues. Reallocate name   |\n    |                        |            | buffer and append callback data to it      |\n     ------------------------ ------------ --------------------------------------------\n    | field                  | on_h_value | Value for current header started. Allocate |\n    |                        |            | new buffer and copy callback data to it    |\n     ------------------------ ------------ --------------------------------------------\n    | value                  | on_h_value | Value continues. Reallocate value buffer   |\n    |                        |            | and append callback data to it             |\n     ------------------------ ------------ --------------------------------------------\n\n\nParsing URLs\n------------\n\nA simplistic zero-copy URL parser is provided as `http_parser_parse_url()`.\nUsers of this library may wish to use it to parse URLs constructed from\nconsecutive `on_url` callbacks.\n\nSee examples of reading in headers:\n\n* [partial example](http:\u002F\u002Fgist.github.com\u002F155877) in C\n* [from http-parser tests](http:\u002F\u002Fgithub.com\u002Fjoyent\u002Fhttp-parser\u002Fblob\u002F37a0ff8\u002Ftest.c#L403) in C\n* [from Node library](http:\u002F\u002Fgithub.com\u002Fjoyent\u002Fnode\u002Fblob\u002F842eaf4\u002Fsrc\u002Fhttp.js#L284) in Javascript\n","http-parser 是一个用 C 语言编写的 HTTP 请求\u002F响应解析器。其核心功能包括解析 HTTP 消息的头部字段、内容长度、请求方法、响应状态码等信息，并支持持久连接（keep-alive）、解码分块传输编码以及升级协议等功能。该解析器设计时考虑了高性能应用的需求，不进行系统调用或内存分配，也不缓冲数据，可以在任何时候中断，每条消息流大约只需要 40 字节的数据存储空间。适用于需要高效处理 HTTP 协议且对性能有较高要求的应用场景，如 Web 服务器。尽管该项目已不再积极维护，对于新项目或考虑迁移的现有项目，建议转向 llhttp 作为替代方案。",2,"2026-06-11 03:07:03","top_language"]