This dictionary for now only contains the subject and issuer names
from the client certificate (if one was provided) with their
X509_NAME components.
Eg:
{
"issuer": {
"C": "SE",
"O": "kore autogen: x509name-test",
"CN": "localhost"
},
"subject": {
"C": "SE",
"O": "kore autogen: x509name-test",
"CN": "localhost"
}
}
When a kore.socket() is closed from any coroutine, make sure any other
coroutines waiting on events on the socket are awoken so they properly
can return errors.
- Make sure we drain the worker log channel if it dies
so we can flush out any lingering log messages.
- Get rid of the raise() in the parent to signal ourselves
we should terminate. Instead depend on the new kore_quit.
- Always attempt to reap children one way or the other.
This will generate an asset file for Kore based on the source file
or directory given.
This allows other build systems to more easily generate asset
files if their compilation steps are different.
These will spew out the required CFLAGS and LDFLAGS respectively
when compiling source code for use in Kore applications.
This should make it easier to integrate this into existing
build systems where using kodev may be a bit annoying.
Eg: gcc -Wall -std=c99 `kodev cflags` koreapp.c `kodev ldflags` -o koreapp.so
If set, will call a given handler with the prototype of
`void body_chunk(struct http_request *req, const void *data, size_t len);`
for each chunk of the received HTTP body, allowing a developer to handle
it in their own way.
The incoming body is still being handled and retained in the same way
as before (in a kore_buf or temporary file).
While here, allow HTTP_STATUS_CONTINUE to work via http_response() and
make the handling of incoming HTTP header data a bit better.
Introduce an on_headers callback for routes, allowing one to inspect
the headers before the request is processed further.
Additionall,
Add a new way of obtaining HTTP headers. Much like http_argument_get_*()
functions, these new APIs allow you to fetch the data of an HTTP header
as a specified C type.
The new APIs are:
* http_request_header_int16()
* http_request_header_uint16()
* http_request_header_int32()
* http_request_header_uint32()
* http_request_header_int64()
* http_request_header_uint64()
* http_request_header_float()
* http_request_header_double()
Should make it easier to operate in HTTP header data in a safe way.
No need to always roll your own string to int conversion functions.
Routes are now configured in a context per route:
route /path {
handler handler_name
methods get post head
validate qs:get id v_id
}
All route related configurations are per-route, allowing multiple
routes for the same path (for different methods).
The param context is removed and merged into the route context now
so that you use the validate keyword to specify what needs validating.
