Adding the hooks keyword with a dictionary attached to specify
the relevant hooks will hook them for the given route.
Eg:
domain.route("/", self.index, methods=["get"],
hooks={
"on_free": self.request_free
}
)
These are the same hooks available via a normal Kore route configuration.
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.
Since its an HTTP response function it functions like http_response() but
takes a kore_json_item pointer that it will automatically convert to a kore_buf
and send/free using http_response_stream().
While here fix a problem with http_response_stream() which could end up
not calling the cb() in case of HTTP_METHOD_HEAD. Since the behaviour is
that it should call cb() when done it should do so immediately.
Joris Vink
Joel Arbring