michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/subsys/net/lib/http/Kconfig

100 lines
2.1 KiB
Text
Raw Normal View History

iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
# Copyright (c) 2016 Intel Corporation
#
license: Replace Apache boilerplate with SPDX tag Replace the existing Apache 2.0 boilerplate header with an SPDX tag throughout the zephyr code tree. This patch was generated via a script run over the master branch. Also updated doc/porting/application.rst that had a dependency on line numbers in a literal include. Manually updated subsys/logging/sys_log.c that had a malformed header in the original file. Also cleanup several cases that already had a SPDX tag and we either got a duplicate or missed updating. Jira: ZEP-1457 Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c Signed-off-by: David B. Kinder <david.b.kinder@intel.com> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-01-18 17:01:01 -08:00
# SPDX-License-Identifier: Apache-2.0
iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
#
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
config HTTP
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
bool "HTTP support"
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
default n
help
This option enables the HTTP library
config HTTP_SERVER
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
bool "HTTP server support"
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
default n
net/http: let HTTP_SERVER, HTTP_CLIENT and HTTP_PARSER select HTTP Due to commit 8308b9bd2d55 ("net/http: Add the HTTP/1.1 API") every user of CONFIG_HTTP_PARSER would need to add CONFIG_HTTP to their .conf files. Which is fine for intree samples/tests as they have been adjusted, but the rest of world working on Zephyr apps will need to make this changes as well. Instead, we should have each of the following select HTTP instead of depend on it, which will make future use of these configs and their dependencies more intuitive: HTTP_SERVER HTTP_CLIENT HTTP_PARSER NOTE: As cleanup, this commit also removes the CONFIG_HTTP added to samples and test .conf files. Change-Id: I81cfaa19e37333b1bf98778f8147814780e7f77c Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-03-14 11:02:00 -07:00
select HTTP
net: http: Add HTTP server library support This commit creates a HTTP server library. So instead of creating a complex HTTP server application for serving HTTP requests, the developer can use the HTTP server API to create HTTP server insteances. This commit also adds support for creating HTTPS servers. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-05-08 14:27:29 +03:00
select HTTP_PARSER
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
help
Enables HTTP server routines
net: http: Add HTTP server library support This commit creates a HTTP server library. So instead of creating a complex HTTP server application for serving HTTP requests, the developer can use the HTTP server API to create HTTP server insteances. This commit also adds support for creating HTTPS servers. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-05-08 14:27:29 +03:00
config HTTP_SERVER_CONNECTIONS
int "Max number of HTTP server connections"
default NET_MAX_CONTEXTS
depends on HTTP_SERVER
help
This value determines how many simultaneous HTTP connections the
HTTP server can serve.
config HTTP_SERVER_NUM_URLS
int "Max number of URLs that the HTTP server will handle"
default 8
depends on HTTP_SERVER
help
This value determines how many URLs this HTTP server can handle.
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
config HTTP_HEADER_FIELD_ITEMS
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
int "HTTP header field max number of items"
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
depends on HTTP_SERVER
default 8
help
Number of HTTP header field items that an HTTP server
application will handle
config HTTP_CLIENT
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
bool "HTTP client support"
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
default n
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
select HTTP_PARSER
net/http: let HTTP_SERVER, HTTP_CLIENT and HTTP_PARSER select HTTP Due to commit 8308b9bd2d55 ("net/http: Add the HTTP/1.1 API") every user of CONFIG_HTTP_PARSER would need to add CONFIG_HTTP to their .conf files. Which is fine for intree samples/tests as they have been adjusted, but the rest of world working on Zephyr apps will need to make this changes as well. Instead, we should have each of the following select HTTP instead of depend on it, which will make future use of these configs and their dependencies more intuitive: HTTP_SERVER HTTP_CLIENT HTTP_PARSER NOTE: As cleanup, this commit also removes the CONFIG_HTTP added to samples and test .conf files. Change-Id: I81cfaa19e37333b1bf98778f8147814780e7f77c Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-03-14 11:02:00 -07:00
select HTTP
net/http: Add the HTTP/1.1 API This patch adds the HTTP/1.1 API for Zephyr. This API consists of client and server context structures enabled via Kconfig variables. HTTP parser support is enabled via the CONFIG_HTTP_PARSER configuration variable. Currently, this API only includes support for writing HTTP requests (client mode) and HTTP responses (server mode). TLS support is not considered in this iteration. Supported HTTP methods: GET, HEAD, OPTIONS and POST. Supported HTTP responses: 400, 403 404. The http_response routine may be used to write any HTTP status code, for example 200 OK. Jira: ZEP-1701 Change-Id: Ic9ccd4d4578d6d0f3a439976ea332b031644ca7d Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2017-02-21 15:02:00 -06:00
help
Enables HTTP client routines
iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
config HTTP_PARSER
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
bool "HTTP Parser support"
iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
default n
net/http: let HTTP_SERVER, HTTP_CLIENT and HTTP_PARSER select HTTP Due to commit 8308b9bd2d55 ("net/http: Add the HTTP/1.1 API") every user of CONFIG_HTTP_PARSER would need to add CONFIG_HTTP to their .conf files. Which is fine for intree samples/tests as they have been adjusted, but the rest of world working on Zephyr apps will need to make this changes as well. Instead, we should have each of the following select HTTP instead of depend on it, which will make future use of these configs and their dependencies more intuitive: HTTP_SERVER HTTP_CLIENT HTTP_PARSER NOTE: As cleanup, this commit also removes the CONFIG_HTTP added to samples and test .conf files. Change-Id: I81cfaa19e37333b1bf98778f8147814780e7f77c Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-03-14 11:02:00 -07:00
select HTTP
iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
help
This option enables the http_parser library from nodejs.
This parser requires some string-related routines commonly
libc: rework libc selection and reduce Kconfigs Moved all libc Kconfigs to where the code is and remove the default Kconfig for selecting the minimal libc. Minimal libc is now the default if nothing else is configured in. Removed the options for extended libc, this obviously was restricting features in the minimal libc without a good reason, most of the functions are available directly when using newlib, so there is no reason why we need to restrict those in minimal libc. Jira: ZEP-1440 Change-Id: If0a3adf4314e2ebdf0e139dee3eb4f47ce07aa89 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2016-12-15 11:16:55 -05:00
provided by a libc implementation.
iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
config HTTP_PARSER_STRICT
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
bool "HTTP strict parsing"
iot: Add HTTP support for Zephyr This commit adds HTTP message handling support for Zephyr. So, no network routines are involved at this level. To add HTTP message handling support for Zephyr, we explored the following options: 1. Importing an external project and perhaps adapting it to fit our requirements. The criteria to pick one codebase among all the available projects are: licensing, correctness and performance. 2. Writing our own implementation from scratch. We decided to import an external project instead of implementing our own parser, mainly due to code maturity and correctness. It could take more time to obtain a production-ready parser from scratch than adapting a state-of-art library. The following is a list of some projects offering similar functionality. lighttpd (many files) * License: revised BSD license * Supported: active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. nginx (src/http/ngx_http_parse.c) * License: 2-clause BSD-like * Supported: very active * Comments: this parser can't be integrated to Zephyr due to dependencies that currently are not satisficed by our SDK. wget (src/http-parse.c) * License: GPL 3.0 * Supported: very active * Comments: this code can't be included in Zephyr due to licensing issues curl (lib/http.c) * License: MIT/X derivate, see: https://curl.haxx.se/docs/copyright.html * Supported: very active * Comment: it must be forked and adapted to run in Zephyr. It is not optimized for low-power devices. nodejs http-parser (http_parser.c) * License: nginx license (2-clause BSD-like) and MIT license * Supported: very active * Comments: optimized with performance in mind. From https://github.com/nodejs/http-parser: "It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. It only requires about 40 bytes of data per message stream." So, nodejs/http-parser looks a very good choice for Zephyr. In this commit, we integrate nodejs' parser to Zephyr. Origin: https://github.com/nodejs/http-parser/releases/tag/v2.7.1 https://github.com/nodejs/http-parser/archive/v2.7.1.tar.gz NOTE: This patch reformats the http_parser files to reduce checkpatch warnings. Changes made in this refactoring are available at: Repo: https://gitlab.com/santes/http_parser/commits/refactoring1 Commit: 9ccfaa23f1c8438855211fa902ec8e7236b702b1 Jira: ZEP-346 Jira: ZEP-776 Change-Id: I29b1d47f323a5841cd4d0a2afbc2cc83a0f576f0 Signed-off-by: Flavio Santes <flavio.santes@intel.com>
2016-08-31 21:46:36 -05:00
default n
depends on HTTP_PARSER
help
This option enables the strict parsing option
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
net: http: Add HTTP server library support This commit creates a HTTP server library. So instead of creating a complex HTTP server application for serving HTTP requests, the developer can use the HTTP server API to create HTTP server insteances. This commit also adds support for creating HTTPS servers. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-05-08 14:27:29 +03:00
config HTTPS
bool "HTTPS support"
default n
depends on HTTP
depends on MBEDTLS
help
Enables HTTPS support.
config HTTPS_STACK_SIZE
int "HTTPS thread stack size"
default 8192
depends on HTTPS
help
HTTPS thread stack size. The mbedtls routines will use this stack
thus it is by default very large.
config HTTPS_HEAP_SIZE
int "HTTPS heap size for mbedtls"
default 12000
depends on HTTPS
depends on MBEDTLS
help
HTTPS heap size. The mbedtls routines will use this heap if enabled.
See ext/lib/crypto/mbedtls/include/mbedtls/config.h and
MBEDTLS_MEMORY_BUFFER_ALLOC_C option for details. This option is not
enabled by default.
http: client: Create a HTTP library Instead of separate sample application that does everything related to HTTP client connectivity, create a HTTP client library that hides nasty details that are related to sending HTTP methods. After this the sample HTTP client application is very simple and only shows how to use the client HTTP API. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2017-04-25 17:58:18 +03:00
config NET_DEBUG_HTTP
bool "Debug HTTP"
default n
depends on HTTP && NET_LOG
help
Enables HTTP output debug messages
Copy permalink